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
Operations

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:
Duplicate
 

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 made changes - 09/Jan/12 06:11 AM
Field Original Value New Value
Assignee Alexander Peshkov [ alexpeshkoff ]
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 made changes - 10/Jan/12 01:17 PM
Status Open [ 1 ] Open [ 1 ]
Target 3.0 Beta 1 [ 10332 ]
Alexander Peshkov made changes - 10/Jan/12 01:17 PM
Priority Critical [ 2 ] Major [ 3 ]
Alexander Peshkov made changes - 16/Jan/12 02:59 PM
Summary Client Library Hangs Forever after unsuccessful connection to remote auxiliary (events) port Client Library Hangs after unsuccessful connection to remote auxiliary (events) port
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.

Alexander Peshkov made changes - 16/Jan/12 03:02 PM
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s 3.0 Alpha 1 [ 10331 ]
Resolution Fixed [ 1 ]
Pavel Cisar made changes - 23/Apr/13 01:32 PM
Status Resolved [ 5 ] Closed [ 6 ]
Pavel Zotov made changes - 18/Jan/16 04:08 PM
Status Closed [ 6 ] Closed [ 6 ]
QA Status No test
Vlad Khorsun made changes - 26/Feb/18 11:44 AM
Link This issue is duplicated by CORE-5597 [ CORE-5597 ]
Vlad Khorsun added a comment - 26/Feb/18 11:47 AM
Alex,

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?