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
Client Library Hangs after unsuccessful connection to remote auxiliary (events) port [CORE3718] #4066
Comments
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
Commented by: @AlexPeshkoff Confirmed on linux, at least for 2.1. |
Commented by: @AlexPeshkoff What I've seen on linux is another bug, causing all server to hang indefinitely due to races. I mark an issue to be fixed before 3.0 beta cause this is really not a good behavior. To avoid such long waits please set ConnectionTimeout to something about 1-2 seconds for LANs, for WANs this depends upon expected timeouts. |
Modified by: @AlexPeshkoffpriority: Critical [ 2 ] => Major [ 3 ] |
Modified by: @AlexPeshkoffsummary: Client Library Hangs Forever after unsuccessful connection to remote auxiliary (events) port => Client Library Hangs after unsuccessful connection to remote auxiliary (events) port |
Commented by: @AlexPeshkoff The fix requires protocol change (new operation), therefore has no chances to be backported to earlier versions. |
Modified by: @AlexPeshkoffstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 3.0 Alpha 1 [ 10331 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Commented by: @hvlad Alex, is it correct that ConnecitonTimeout could be changed at server side ? |
Commented by: @AlexPeshkoff Don't know. Why do you ask such question? How is it related here? |
Submitted by: Mark Jones (mjnz)
Is duplicated by CORE5597
After an unsuccessful attempt to connect the auxiliary port (isc_que_events) any subsequent api call that needs to communicate with the server hangs forever (so the client application hangs forever)
Configure the server (superserver) so that the firewall does not block the main service port (3050) but blocks the specified Aux port (3060 in this case)
--- firebird.conf ---
#RemoteServiceName = gds_db
#RemoteServicePort = 3050
RemoteAuxPort = 3060
------
Make a connection to the remote server using tcp/ip then call isc_que_events which will timeout after 10-15 seconds with a isc_network_error (335544721). Now make a call that requires communication with the server (e.g. isc_start_transaction ) and the application (library) will hang forever
Right now I can see that it goes wrong when it tries to send the subsequent packet to the server ( port->send(packet) ) but the debugger didnt go any further into the code from there so unsure excatly where after that it fails.
Commits: 0c7d2c2
The text was updated successfully, but these errors were encountered: