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
Adjust comment of DummyPacketInterval in fb.conf [CORE6036] #6286
Comments
Commented by: @asfernandes The options seems to say that if server has this option, it could crash clients running in Windows NT4 or Windows 2000 pre SP3. Clients (for example Jaybird) may run on that OS then the server option comment may be relevant. Can anyone confirm? |
Commented by: @WarmBooter I'm not a Java guy, but seems that Java 7 and 8 cannot run in Windows NT or Win2K either: https://www.java.com/en/download/help/sysreq.xml |
Commented by: @asfernandes But I think it doesn't matter. You can substitute Java+Jaybird with a C application reimplementing the protocol, or a old client working in these OS. Didn't the same thing is still valid? A server config. may crash the client? |
Commented by: @WarmBooter Well, I will only comment based on my experience: I have this setting enabled in several customers, for years, and never had the described problem. In the other side, I see several people suffering with "ghost connections" (specially when they use WIFI connections) causing stuck OAT and frozen GC. That comment usually frights the DBA, who prefers to not touch the setting. |
Commented by: @dyemanov IIRC, the issue is the following. Server regularly pings the client with op_dummy packets. The client doesn't wait for them explicitly, they're processed when the client has something to send to the server. If the client is idle, dummy packets are collected inside the TCP stack incoming buffer, which (at least in older Windows versions) is located in the non-paged kernel memory. If the client is longly idle (app is left open for the weekend, for example) it may lead to either client crash or error (system memory overflow) thrown for the connection. Personally, I think this comment sounds more dangerious than the issue actually is. It may be a PITA for application servers and other n-tier architectures, but surely not the end of the world for regular client connections. I always recommend to turn this option on. |
Commented by: @WarmBooter So, I suggest to enable this option by default in the next releases of Firebird. How many NT or Win2K (pre SP3) installs are out there nowadays? Probably a very small number, so it makes much more sense to have it enabled to bring its benefits for the majority of the users, and let the dinosaurs disable it if they need to. |
Commented by: Stefan Heymann (stefanheymann) As we have talked on the Firebird Conference in Berlin 2019: This comment in firebird.conf is outdated and might lead people to not using this (important) feature. We should remove that comment. Or at least add something that it is safe to use from Windows 2003 on. I also support the idea of setting this to 60 or 120 by default. |
Submitted by: @WarmBooter
Votes: 1
# NOTE. This option may hang or crash Windows NT4 or Windows 2000 pre SP3
# on the client side as explained here:
# http://support.microsoft.com/default.aspx?kbid=296265.
# or may not prevent eventual inactive client disconnection for other OS.
Firebird 3 can't run on Windows NT and Windows 2000 (MSVC 10 is not support in those Windows versions), so it doesn't make sense to have such comment in fb.conf. Please remove it for the next releases/subreleases.
The text was updated successfully, but these errors were encountered: