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
Comments
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. |
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. |
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. |
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. |
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 ? |
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? |
Commented by: @pavel-zotov When test with ~200 connections is running lot of events occur in such *huge* duration: one SECOND. |
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. |
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. |
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& |
Commented by: @pavel-zotov --- Alex --- 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 ? |
Commented by: @dyemanov Pavel, I feel this is becoming off-topic here. Please continue this discussion privately. |
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.
The text was updated successfully, but these errors were encountered: