Roy Lambert wrote:
>
> Since it seems to be the logon/startup of the app which causes the problem why not try a special version which writes out log messages to a file. You can make it as fine as you like, even after each line of code. That at least should allow you to pinpoint where the problem is.
>
> My only other suggestion is to get them to change the machine used as the fileserver (use one of the workstations for experimentation) in case its the network setting and not releasing a lock.
>

They are running such a special version now, but because the application
hangs and they have to end-task it, how much do you trust the
information in the log to be complete?  Were entries generated by the
logging function actually written to disk, or lost in the buffer when
the task was killed?  CodeSite uses a special dispatcher to receive and
log messages (very useful when trying to debug painting or drawing
problems) so I think the log is complete, but I can't be sure.

At this point in time, it appears the program hangs as it is opening
tables.  (I log a message just before the Open statement.)  To open the
tables, the app cycles through the Datamodule components, opening any
object that is a DBISAMTable...

if (Components[i] is TDBISAMTable) then begin
  try
    with TDBISAMTable(Components[i]) do begin
      sStopWords := TextIndexStopWords;
      Exclusive:=False;
      ReadOnly:=False;
      Open;
      if ReadOnly = True then begin
        {Display message about read only access}
        Application.Terminate;
        Exit;
      end;
    end;
  except
    on E: EDBISAMEngineError do begin
      {exception handling messages
    end;
  end;
end;

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon


In that case - how far away from you are they?

Roy Lambert

Gordon,

Have you made sure that all anti-virus software is turned off? I have
seen long delays in opening tables due to AV issues but never full
hangs... but one never knows. What happens if you open two application
instances on the same machine?  If it hangs in that case maybe you can
reproduce it at your site.

Good luck,

Sean

Gordon Turner wrote:
> Roy Lambert wrote:
>>
>> Since it seems to be the logon/startup of the app which causes the
>> problem why not try a special version which writes out log messages to
>> a file. You can make it as fine as you like, even after each line of
>> code. That at least should allow you to pinpoint where the problem is.
>>
>> My only other suggestion is to get them to change the machine used as
>> the fileserver (use one of the workstations for experimentation) in
>> case its the network setting and not releasing a lock.
>>
>
> They are running such a special version now, but because the application
> hangs and they have to end-task it, how much do you trust the
> information in the log to be complete?  Were entries generated by the
> logging function actually written to disk, or lost in the buffer when
> the task was killed?  CodeSite uses a special dispatcher to receive and
> log messages (very useful when trying to debug painting or drawing
> problems) so I think the log is complete, but I can't be sure.
>
> At this point in time, it appears the program hangs as it is opening
> tables.  (I log a message just before the Open statement.)  To open the
> tables, the app cycles through the Datamodule components, opening any
> object that is a DBISAMTable...
>
> if (Components[i] is TDBISAMTable) then begin
>   try
>     with TDBISAMTable(Components[i]) do begin
>       sStopWords := TextIndexStopWords;
>       Exclusive:=False;
>       ReadOnly:=False;
>       Open;
>       if ReadOnly = True then begin
>         {Display message about read only access}
>         Application.Terminate;
>         Exit;
>       end;
>     end;
>   except
>     on E: EDBISAMEngineError do begin
>       {exception handling messages
>     end;
>   end;
> end;
>

Progress Report...

(Thanks all for your suggestions and ideas.)

The customer let the second workstation run for a while and it
eventually connected to all of the tables (it took several minutes), so
the application will connect, it just seems to take a long time.

Unfortunately, I wasn't smart enough to include time stamps or tick
counts in the debugging messages last time, so I'm not sure exactly
where the delays occurred, but I'm going to do that now.  (I prepare
several queries after the data files are opened.)

(I'll also mention the AV option to see if that has an impact, but since
 the first connection happens normally, I'm not sure if this is a factor.)

Tim...

Are there retry loops in the DBISAM table component code that may be
executing a number of times before actually connecting?  Is there some
aspect of network setup or traffic that we should look at for time delays?

Everyone...

Is there any other debugging information I should try to gather for the
next pass?

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon,

I would also make sure OpLocks are disabled in the OS. The problem could
also be caused by a delay in the request for the first workstation to
release the exclusive lock on the file & drop it down to shared so that
the second workstation can begin to use the file.

Sean

Gordon Turner wrote:
> Progress Report...
>
> (Thanks all for your suggestions and ideas.)
>
> The customer let the second workstation run for a while and it
> eventually connected to all of the tables (it took several minutes), so
> the application will connect, it just seems to take a long time.
>
> Unfortunately, I wasn't smart enough to include time stamps or tick
> counts in the debugging messages last time, so I'm not sure exactly
> where the delays occurred, but I'm going to do that now.  (I prepare
> several queries after the data files are opened.)
>
> (I'll also mention the AV option to see if that has an impact, but since
>  the first connection happens normally, I'm not sure if this is a factor.)
>
> Tim...
>
> Are there retry loops in the DBISAM table component code that may be
> executing a number of times before actually connecting?  Is there some
> aspect of network setup or traffic that we should look at for time delays?
>
> Everyone...
>
> Is there any other debugging information I should try to gather for the
> next pass?
>

Gordon

Change the server registry at following key and check if it helps.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

autodisconnect                    REG_DWORD      0xffffff
enableforcedlogoff             REG_DWORD      0x1
enablesecuritysignature       REG_DWORD      0
EnableOplocks                 REG_DWORD      0
CachedOpenLimit               REG_DWORD      0

Eduardo

Sean,

<< I would also make sure OpLocks are disabled in the OS. The problem could
also be caused by a delay in the request for the first workstation to
release the exclusive lock on the file & drop it down to shared so that the
second workstation can begin to use the file. >>

Yes, it is possible that this may be the case.

--
Tim Young
Elevate Software
www.elevatesoft.com

Gordon,

<< The customer let the second workstation run for a while and it eventually
connected to all of the tables (it took several minutes), so the application
will connect, it just seems to take a long time. >>

See my response to Sean.  He may be on to something here - it may be that
the OpLocks are taking too long to get rid of the exclusive open and make
the files available for shared use.  It certainly would explain the
environmental aspect of things and why it works fine for most clients but
not this one.  Given that the application isn't changing at all, it has to
be something environmental.

<< Are there retry loops in the DBISAM table component code that may be
executing a number of times before actually connecting? >>

Only in terms of waiting for a read lock to read the table headers.
However, unless the first workstation is taking several minutes to create
the tables, then this won't have any bearing on the situation because that's
the only way that a read lock would be blocked out for that long.  If the
first workstation pops right up, but the second workstation keeps waiting
and waiting, then I would look into the above issue with the OpLocks.

--
Tim Young
Elevate Software
www.elevatesoft.com