Hi

I have RemoteTimeout set to the default of 180 seconds in my TEDBSession.

But when my Session is opened and the server isn't available, then the
delay to getting the EDB_ERROR_CLIENTCONN exception is about 22 seconds
(timed by counting in my head).

Is there a different property that controls how long it searches for the
server before the exception?

Cheers

Jeff

Jeff Cook wrote:

> I have RemoteTimeout set to the default of 180 seconds in my
> TEDBSession.
>
> But when my Session is opened and the server isn't available, then
> the delay to getting the EDB_ERROR_CLIENTCONN exception is about 22
> seconds (timed by counting in my head).

I presume the timeout is when the connection exists and stops
responding. The first connection is either there or not - why would you
wait so long for it? And if it doesn't matter, you can retry in your
own code. I'd want to know as soon as possible that the server is not
there at all. (You may have other ideas of course!)

--

Matthew Jones

Jeff,

<< But when my Session is opened and the server isn't available, then the delay to getting the EDB_ERROR_CLIENTCONN exception is about 22 seconds (timed by counting in my head). >>

These are two different things.  The TEDBSession.RemoteTimeout property controls how long the EDB session will wait for a reply from the EDB Server during a request.

What you're seeing is a *connection* timeout, which is controlled at the Winsock layer, and unfortunately there isn't any way to set that value in Windows.

Tim Young
Elevate Software
www.elevatesoft.com

Hi Matthew

The problem is that there is long wait if the server *really* isn't
available.  In this case my app tries a backup server.  Twenty or so
seconds isn't really long to wait but some users are so impatient ...

Anyway, Tim has put his finger on the reason and them pesky users will
just have to learn that patience is a virtue.

Cheers

Jeff

On 8/08/2015 1:20 a.m., Matthew Jones wrote:
> Jeff Cook wrote:
>
>> I have RemoteTimeout set to the default of 180 seconds in my
>> TEDBSession.
>>
>> But when my Session is opened and the server isn't available, then
>> the delay to getting the EDB_ERROR_CLIENTCONN exception is about 22
>> seconds (timed by counting in my head).
>
> I presume the timeout is when the connection exists and stops
> responding. The first connection is either there or not - why would you
> wait so long for it? And if it doesn't matter, you can retry in your
> own code. I'd want to know as soon as possible that the server is not
> there at all. (You may have other ideas of course!)
>

On 8/08/2015 1:52 a.m., Tim Young [Elevate Software] wrote:
>
.... and unfortunately there isn't any way to set that value in Windows.
>
Thanks for that Tim

Cheers

Jeff

Jeff Cook wrote:

> The problem is that there is long wait if the server really isn't
> available.  In this case my app tries a backup server.  Twenty or so
> seconds isn't really long to wait but some users are so impatient ...

You could try both at the same time. You would probably want to wait a
little before going with the backup server in case the primary is just
being slow, but it would tell you what you need to know as fast as
possible. Depends of course on your backup and how the syncronisation
is done etc.

--

Matthew Jones

Jeff,

I can see about adding a "TestConnection" method to the TEDBSession component.  You *can* do a user-defined connection timeout if you try the connection in a thread, and just kill the socket if X number of milliseconds have expired using a timer in the main thread.  However, it's a little tricky to do, so it's best that I just add it.

Tim Young
Elevate Software
www.elevatesoft.com

Sounds excellent, Tim

Not a high priority - hoping that we don't have another server failure
for a long, long while.

Cheers

Jeff

Tanks also to Matthew. J.

On 11/08/2015 1:58 a.m., Tim Young [Elevate Software] wrote:
> Jeff,
>
> I can see about adding a "TestConnection" method to the TEDBSession component.  You *can* do a user-defined connection timeout if you try the connection in a thread, and just kill the socket if X number of milliseconds have expired using a timer in the main thread.  However, it's a little tricky to do, so it's best that I just add it.
>
> Tim Young
> Elevate Software
> www.elevatesoft.com
>