Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISQL: provide ability to specify TIMEOUT in command-line for cancel attempt to establish connect if server is unavaliable [CORE4226] #4550

Open
firebird-automations opened this issue Sep 18, 2013 · 12 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @pavel-zotov

For some kind of tests it will be useful if ISQL will forcely cancel it's attempt to establish connect when some timeout expires and returns to OS with errorlevel > 0. One can immediatelly run scripts to catch stack-trace ot lock-table when connect can not be establish during that time but FB is running and serves other (existing) connections.
Such timeout could be specified via command-line argument, something like this:

ISQL my_poor_database.fdb -i my_script.sql -t 3000 // wait max. 3000 millisecond and return to OS if this timeout expires.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

I doubt this is possible on the client side, considering the synchronous nature of the remote protocol. So perhaps it should be not about ISQL but instead about the engine returning failure if it cannot create the connection during the specified timeout (should isc_dpb_connection_timeout be reused?). But it means that time passed should be checked virtually per every operation while attaching. IMHO, it would add a significant overhead and would overcomplicate the code. Alternatively, we could use an asynchronous timer, but wouldn't it require a separate thread launched per every "limited" connection? It would also be an overkill. So far I see more questions than answers here.

@firebird-automations
Copy link
Collaborator Author

Commented by: @pavel-zotov

Unfortunately, the mystery with connects that establish in extremely long time (> 10 seconds) still alive. And there is no way to predict exact moment at which such 'too long' connect will occur. The sequence of measured times can be like this (in milliseconds): 60, 130, 70, 90, 290, 50, 9500 (yes: more than 9 seconds), 70, 90, ...

So, we know about such strange fact only AFTER it occur and all connect establishing "context" has gone.
And catch stack-traces ot lock-table *after* this moment is useless.

@firebird-automations
Copy link
Collaborator Author

Commented by: @pavel-zotov

> Alternatively, we could use an asynchronous timer, but wouldn't it require a separate thread launched per every "limited" connection?

"Who" will launch this timer which should watch for connection establishing ? If ISQL application (i.e. CLIENT that attempts to connect) - then why you say about 'overkilling' ? It will be only the problem of client machine rather than server.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

I was talking about the engine. And if this ticket is *only* about tracking/debugging longish connection attempts, then it's likely to be rejected. It should have some general use for being accepted.

@firebird-automations
Copy link
Collaborator Author

Commented by: @pavel-zotov

But what about 'mystery' which I mentioned above ? How we can "catch" FB state just at that moment (maybe with gap ~0.5 second) when strange long connect occurs ?

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

I don't have a problem with the request, I wonder if defining the timeout in _milliseconds_ is really required, why can't simple seconds be used?

@firebird-automations
Copy link
Collaborator Author

Commented by: @pavel-zotov

When test with ~200 connections is running lot of events occur in such *huge* duration: one SECOND.
The more precisely is our tool - the better. IMHO.

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Dmitry, on my mind this feature may be very useful when establishing any network connections. Imagine one is running time-critical script and invokes isql to do something on remote server. Normally this takes one opr two seconds. But delays due to network problems >10 seconds are undesired. At least this is what for dpb connect timeout parameter was designed. What's suggested is just support of this API feature at isql level. And certainly this is not related to engine - it's client-inly feature. (BTW, this parameter is parsed by ebgine but never used.)

What about second/milliseconds - certainly it's long ago XXI century, and second was good precision unit in XX century. Pn the other hand such change required one more parameter in DPB, and I'm not absolutely sure it's needed. On the other hand even such API change may be generally useful - seconds precision may be really not enough.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Alex, I have no problems supporting isc_dpb_connect_timeout in ISQL. But Pavel is talking about the *engine* slowly responding to connect requests. In other words, he wants to wait M secs, "unblock" the isc_attach_database() call and force some kind of engine dump to know what the engine is doing so long.

But even if we ignore such "special" usage, the fact remains that sometimes connections are established slowly not because of the network issues but because of the heavily loaded server. And it can be expected that time-critical scripts you mentioned as an example may need to react on that as well, meaning that isc_dpb_connect_timeout should be taken into account inside the engine as well. But this opens a pandora box with all the issues I described in the prior comment.

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

I.e. this is already not CONNECT timeout, but ATTACH one? I see that currently in remote code isc_dpb_connect_timeout is taken into an account only before connection is established. This is (sooner of all) not what Pavel needs. For remote connection we can easily (more or less) change this in network redirector. But as soon as embedded connections are also taken into an account engine support is needed.

In trunk changes needed in engine are not so awful. We have generic timer which can be activated in the beginning of attachDatabase, i.e. no separate thread is needed. But even with this we should learn engine to check shutdown flags during attach, add timeouts to all locks taken during attach, and hell knows what else. I.e. I agree - this feature is not for fb3.

BTW, Pavel's problem may be easily solved using shell-only tools.

isql -user user -pas passwd localhost:DB -i script.sql&
sleep $delay #⁠ delay in seconds, but may be in form 0.15, i.e. 150ms
ps -p $! && doDumps

@firebird-automations
Copy link
Collaborator Author

Commented by: @pavel-zotov

--- Alex ---
isql -user user -pas passwd localhost:DB -i script.sql&
sleep $delay #⁠ delay in seconds, but may be in form 0.15, i.e. 150ms
ps -p $! && doDumps
-------

What is "doDumps" here ? Can I use your recent patch that tightly catch Lock Table and prevent any activity inside FB to get stack trace of firebird process ?

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Pavel, I feel this is becoming off-topic here. Please continue this discussion privately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant