Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 21 to 28 of 28 total |
1107 The session ID 4 is no longer present on the server |
Thu, Jan 7 2016 10:52 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
>You can't, is the answer. It's mostly irrelevant in the scope of the reconnects, anyways. A better determination is how many reconnects have been attempted. If the number is greater than 4-6, then most likely the connection is down for good. OK what's the best way to get that information? I was going to suggest something along the lines of dm.TfRSession.Execute('select * from configuration.logevents where ....') then realised I don't have a connection to do that with - so increment a local variable in the reconnect event I suppose. It looks as though the reconnects are happening pretty quickly so hold the time of the last one and if more than 15 seconds ago reset the counter to zero. Because this is the code handling email download if its in there I have to wait for whatever rogue email is causing it. Its one of those incredibly annoying ones that MadExcept doesn't trap either. The last one of those involved problems when the notebook screen powered off - powering back on caused a random AV. Roy Lambert |
Thu, Jan 7 2016 11:13 AM | Permanent Link |
Matthew Jones | Tim Young [Elevate Software] wrote:
> If there's a race condition, then it will normally happen with more > activity. ALways worth generating artificial activity too. I usually write code to "mock" activity in threads, so I can hammer a server for testing. But the most interesting one was when we used the MonoTouch system for an iPhone app, and it would crash after about 5 hours, with the app doing a REST call every ten seconds. We turned off all the multi-threading, still happened. Tweaked it to just do the REST call over and over, and it would crash within 10 mins, usually less, always. Turned out to be a bug in the garbage collector of Mono (all versions!). They issued a fix the day before Novell canned the MonoTouch project, which allowed us to ship. I wonder whatever became of that project. Anyway, if there is suspect threading code, hammer it hard. And if madExcept isn't in use, make it so (and add on Exception .. HandleException(etNormal) in key places so they don't get swallowed). -- Matthew Jones |
Fri, Jan 8 2016 3:51 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
><< Not sure how that can AV >> > >Are you sure that's the only function being called ? If Delphi's built in search, and GExpert's search are to be believed - Yes (I used both because sometimes Delphi's search doesn't seem to work) ><< Also don't forget this only appeared after I moved the server from 2.18 to 2.20. Before that it was >> > >It's probably the same thing. I added additional error handling for the modules due to a customer having an issue with an external module that was causing some bad things to happen during session shutdown when there was an AV in an external module. This is basically the problem with external modules (for us): because they run in-process, they can take down the entire server if you're not careful with your code. I opted for this model instead of something like SQL Server, which has process separation, for performance reasons. I have a suspicion that part of the problem is exception handling somehow getting the wrong thing reported. I've had that happen to me a time or two. I've altered how the program responds to errors so I'll see how that goes. Since its emails my suspicion is somewhere in the decoding code but everything is handled properly if I just restart the program and if it crashes the email should be left on the server and I should get the error again. ><< Possibly, but I'm not sure what is racing or how to track it down. >> > >How many users are using the system at a given time ? Is there a time when there are more users than normal ? That's where I would start looking. If there's a race condition, then it will normally happen with more activity. This is on my own version and since I'm OMB these days only one user. >If you want to send me your log (edbconfig.edblog), I can take a look and tell you what I think is happening. I too a copy before I wiped it - I'll email it later on. Roy Lambert |
Fri, Jan 8 2016 4:06 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Matthew
>ALways worth generating artificial activity too. I usually write code >to "mock" activity in threads, I've done similar (including when writing this app), but in this case (its email) I can't simulate it in a meaningful way. As I said in my reply to Tim one guess would be its caused by a rouge email and decoding it screwing up. I have doubts about this because the rouge should stay at the ISP until I manually delete it since the program isn't going to be doing so because it crashes. >Anyway, if there is suspect threading code, hammer it hard. And if >madExcept isn't in use, make it so (and add on Exception .. >HandleException(etNormal) in key places so they don't get swallowed). MadExcept is there but isn't reporting anything, I have a slew of try..except blocks but I don't understand just what you're proposing. Can you explain the Exception .. HandleException(etNormal) for me please. Roy Lambert |
Fri, Jan 8 2016 6:52 AM | Permanent Link |
Matthew Jones | If decoding of emails is involved (rouge, or rogue perhaps, in nature)
then I'd be using the FastMM in the overwrite mode to see if something is writing where it shouldn't. But the madExcept thing is that it can log exceptions at any time you want, even if you handle them. uses madExcept; try // whatever except on errInfo : Exception do begin HandleException(etNormal, errInfo); end; You can of course do other things in the handler, but start with the HandleException and it will log the details as usual. I always have madExcept in "auto continue" mode, so check the options there. Any exception type is okay too. I do this as a wrapper on all threads, in Execute, so that if they fail I get the details, but they don't kill the application completely. -- Matthew Jones |
Fri, Jan 8 2016 9:05 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Matthew
>If decoding of emails is involved (rouge, or rogue perhaps, in nature) I hasten to say I'm RGB colour blind! >then I'd be using the FastMM in the overwrite mode to see if something >is writing where it shouldn't. I just reinstalled the GUI to teh options and looks like that's taken care of. >But the madExcept thing is that it can log exceptions at any time you >want, even if you handle them. > >uses madExcept; > > try > // whatever > except > on errInfo : Exception do > begin > HandleException(etNormal, errInfo); > end; > >You can of course do other things in the handler, but start with the >HandleException and it will log the details as usual. I always have >madExcept in "auto continue" mode, so check the options there. Any >exception type is okay too. > >I do this as a wrapper on all threads, in Execute, so that if they fail >I get the details, but they don't kill the application completely. Interesting. I've only ever bunged it into a project and reacted to whatever came out. I'll have a look at this. Roy Lambert |
Fri, Jan 8 2016 10:27 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< You can't, is the answer. It's mostly irrelevant in the scope of the reconnects, anyways. A better determination is how many reconnects have been attempted. If the number is greater than 4-6, then most likely the connection is down for good. OK what's the best way to get that information? I was going to suggest something along the lines of dm.TfRSession.Execute('select * from configuration.logevents where ....') then realised I don't have a connection to do that with - so increment a local variable in the reconnect event I suppose. It looks as though the reconnects are happening pretty quickly so hold the time of the last one and if more than 15 seconds ago reset the counter to zero. >> That will work. You'll have to essentially adjust how you handle this to your specific needs in terms of how long you want to wait (in total). << Because this is the code handling email download if its in there I have to wait for whatever rogue email is causing it. Its one of those incredibly annoying ones that MadExcept doesn't trap either. The last one of those involved problems when the notebook screen powered off - powering back on caused a random AV. >> An AV in the EDB code, or your code ? I know you said random, but sometimes you can tell if its EDB or not by the error message. Tim Young Elevate Software www.elevatesoft.com |
Sat, Jan 9 2016 10:42 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
><< Because this is the code handling email download if its in there I have to wait for whatever rogue email is causing it. Its one of those incredibly annoying ones that MadExcept doesn't trap either. The last one of those involved problems when the notebook screen powered off - powering back on caused a random AV. >> > >An AV in the EDB code, or your code ? I know you said random, but sometimes you can tell if its EDB or not by the error message. The screen one was caused by a blinker component I'd written (for some reason never discovered if the screen was powered off whilst the blinker was running when the screen came back on it AVd) if this one I have no idea. I've altered my error handling to see if it cures things but it can take weeks (or months) to manifest itself. If it happens again at some future point I'll bite the bullet and remove all error handling in my code in the hope that SOMETHING will show up. Roy Lambert |
« Previous Page | Page 3 of 3 | |
Jump to Page: 1 2 3 |
This web page was last updated on Thursday, May 23, 2024 at 07:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |