Issue Details (XML | Word | Printable)

Key: CORE-3718
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Mark Jones
Votes: 0
Watchers: 2

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

Client Library Hangs after unsuccessful connection to remote auxiliary (events) port

Created: 05/Jan/12 08:54 PM   Updated: 26/Feb/18 12:13 PM
Component/s: API / Client Library
Affects Version/s: 2.5.0, 2.1.4, 2.5.1
Fix Version/s: 3.0 Alpha 1

Environment: Superserver, MS Windows, TCP/IP
Issue Links:

Target: 3.0 Beta 1
QA Status: No test

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

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 09/Jan/12 06:12 AM
Confirmed on linux, at least for 2.1.

Alexander Peshkov added a comment - 10/Jan/12 01:16 PM
What I've seen on linux is another bug, causing all server to hang indefinitely due to races.
This is an old issue, not a regression in 2.1 or 2.5. Your connection did not hang completely, it's just waiting for a ConnectionTimeout which is 180 sec by default. I agree that this is not very good value for today, but do not think it's worth changing default.

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.

Alexander Peshkov added a comment - 16/Jan/12 03:02 PM
The fix requires protocol change (new operation), therefore has no chances to be backported to earlier versions.

Vlad Khorsun added a comment - 26/Feb/18 11:47 AM

is it correct that ConnecitonTimeout could be changed at server side ?

Alexander Peshkov added a comment - 26/Feb/18 12:13 PM
Don't know. Why do you ask such question? How is it related here?