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

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

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

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

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

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

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

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