Dany wrote:

> First of all I want to thank you, Jason, for the pointers
> to services from when I last pitched into the RPL thread.
>
> I am playing around with the sample and I have a question.
>
> <code>
> procedure TsvcUCCSync.DoServiceLoopException( E: Exception );
> begin
> // Check if the problem is actually to do with a broken connection.
> // If it is, set a flag so that the connection can be reset.
> // It is not wise to do it directly here but in the service
> // loop itself.
> if E is EIB_ISCError then
> with E as EIB_ISCError do
> if ConnectionLostErrcode( ERRCODE ) then
> KillCon := true;
> inherited DoServiceLoopException( E );
> end;
> </code>
>
> In the handler above it is very important that the KillCon
> flag is set to true. Otherwise the service will just
> continue to try to use a broken connection. OK.

That's not all. It's also very important because you have no idea what the
callstack getting to that point is and immediately starting to close the
connection could subvert or disrupt more appropriate error handling. This
doesn't cause the exception to be avoided, it merely sets a flag so that
logic elsewhere can understand the connection was lost.

> In IBS_Base, SysExecuteService then repeat loop looks like
> this (pseudo)
>
> <code>
> try
> ... flags and stuff...
> try
> DoServiceItems;
> except
> on E: Exception do
> HandleProblem( 'Problem in DoServiceItems', E );
> end;
> ...more stuff...
> except
> on E: Exception do
> DoServiceLoopException( E );
> end;
> </code>
>
> So... when there is an exception in (for example) DoServiceItems the
> DoServiceException handler is never called because the exception is
> handled one level above. KillCon never gets set and the connection is
> not Disconnected/Connected.
>
> Maybe all I have to do is substitute
> <Code>
> HandleProblem( 'Problem in DoServiceItems', E );
> </code>
> with
> <code>
> begin
> LogItem( 'Problem in DoServiceItems' );
> DoServiceLoopException( E );
> end;
> </code>
> in the inner try except block. Just curious as to the design.
> Am I missing something?

I'm not sure about this part. I'll try and get back to it but it may take a
while.

> Another question about the sample is if you use the
> WakeupThread. I can not seem get my head around the
> TIB_RPL_Sync internals (which I'm not going to use anyway)
> and whether there *is* an event "waking up" the worker
> thread or if DoServiceItems together with DoServiceCanSleep
> is considered enough.

The WakeupThread is the AST (asynchronous trap) that comes in from the
socket and the less you do with it the better. What I have done is
registered things such that the AST sets a flag indicating which event was
triggered and then it actually hits the Windows TEvent to trigger the worker
thread to wakeup immediately so it can get right to work.

> A further small comment about having an IB_Event connected to the
> WakeupThread would be very much appreciated.

Take a look surrounding the OnWakeup event. Look at the TIB_Session level
and the TIB_Event level. Some of this is integrated behind the scenes. You
would also do well to understand the DoPassiveTasks (spelling?) stuff.

> And finally;
>
> The GDS511 stuff. Is that for older versions of IB.
> I'm using FB 1.5.3 but have had problems with software
> unloading after using a localhost TCP/IP connection
> with events.

This is just legacy from when IB 5.6 had a bug in their client but using the
client from IB 5.1 was fine.

Just ignore it for now.

> Thanks a lot!
>
> /Dany

Jason