Issue Details (XML | Word | Printable)

Key: CORE-4226
Type: Improvement Improvement
Status: Open Open
Priority: Minor Minor
Assignee: Unassigned
Reporter: Pavel Zotov
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.
Firebird Core

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

Created: 18/Sep/13 01:43 PM   Updated: 19/Sep/13 09:25 AM
Component/s: ISQL
Affects Version/s: 3.0 Alpha 1
Fix Version/s: None

 Description  « Hide
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.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 18/Sep/13 02:06 PM
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.

Pavel Zotov added a comment - 18/Sep/13 02:14 PM
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.

Pavel Zotov added a comment - 18/Sep/13 02:17 PM
> 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.

Dmitry Yemanov added a comment - 18/Sep/13 02:47 PM
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.

Pavel Zotov added a comment - 18/Sep/13 02:55 PM
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 ?

Sean Leyne added a comment - 18/Sep/13 02:56 PM
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?

Pavel Zotov added a comment - 18/Sep/13 03:12 PM
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.

Alexander Peshkov added a comment - 19/Sep/13 08:07 AM
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.

Dmitry Yemanov added a comment - 19/Sep/13 08:16 AM - edited
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.

Alexander Peshkov added a comment - 19/Sep/13 09:06 AM
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

Pavel Zotov added a comment - 19/Sep/13 09:18 AM
--- 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 ?

Dmitry Yemanov added a comment - 19/Sep/13 09:25 AM
Pavel, I feel this is becoming off-topic here. Please continue this discussion privately.