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
Gfix (sweep) is running for 3 days now :( [CORE3375] #3741
Comments
Commented by: @dyemanov I don't think it matters, as it's the engine who performs the sweeping. If there's no sweep connection in the MON$ tables, then it's highly unlikely to be running. Perhaps a zombie connection remained alive. Have you tried killing gfix and restarting it? Make sure that there *is* a sweep connection in the MON$ tables at least after starting the sweep. |
Commented by: vander clock stephane (arkadia) > If there's no sweep connection in the MON$ tables yes actually their is no "gfix.exe" connection in the MON$ table > Have you tried killing gfix and restarting it? Make sure that there *is* a sweep connection in the MON$ tables at least after starting the sweep. just try it now (kill and restart gfix), and yes now their is the "gfix.exe" connection in the MON$ table ... i thing that mean that the connection protocole is still not accurate because it's make the gfix "frozen" waiting undefinitivelly a dead connection... only a hard kill is possible to stop gfix |
Commented by: @dyemanov I'm afraid we can only guess here. This ticket cannot be resolved without a reproducible test case. |
Commented by: vander clock stephane (arkadia) yes i understand, i will try to do a reproducible test case (cut the cable in the middle of the sweep ?) |
Commented by: @dyemanov I cannot suggest anything as I have no clue what was the reason (network or something else). |
Commented by: vander clock stephane (arkadia) now i have the same probleme with gback :( |
Commented by: Sean Leyne (seanleyne) 1 - Do not "hijack" tracker cases for new issues which are related to a different tool 2 - please post your issues to the support list BEFORE creating tracker cases. This case is an example of a support issue not a real bug/engine issue. Once an issue has been confirmed in the support list as a real bug, then you can open a tracker case. |
Commented by: @dyemanov Sean, why do you think it is not a bug? A specific tool has nothing to do here, it's the client library getting blocked. |
Commented by: Sean Leyne (seanleyne) Based on the previous posting I suspect that the issue is there is a network problem |
Commented by: vander clock stephane (arkadia) > 1 - Do not "hijack" tracker cases for new issues which are related to a different tool hmm, i really thing this problem is not as simple as a network matter ! 1. even if it's a matter of a network problem, it's not acceptable (i thing) that the client stay "blocked" for undefnitively if we not manually kill it (i wait several days before to report the bug here to be sure) ! all of this make me more thinging about a deadlock somewhere (or a badly newtork protocal) that the simple network probleme ... > 2 - please post your issues to the support list BEFORE creating tracker cases. This case is an example of a support issue not a real bug/engine issue. Once an issue has been confirmed in the support list as a real bug, then you can open a tracker case. With helen B as an administrator/moderator of theses lists ? it's a joke :) the last time i try she block my messages because it's was about a FB "beta" version and that all questions regarding the "beta" must be write here ! (i can send you her emal if you want to discuss with her about this) anyway thank for you help ! |
Commented by: Sean Leyne (seanleyne) >> 2 - please post your issues to the support list BEFORE creating tracker cases. This case is an example of a support issue not a real bug/engine issue. Once an issue has been confirmed in the support list as a real bug, then you can open a tracker case. >With helen B as an administrator/moderator of theses lists ? it's a joke :) the last time i try she block my messages because it's was about a FB "beta" version and that all questions regarding the "beta" must be write here ! (i can send you her emal if you want to discuss with her about this) Helen is simply enforcing the policy that has been adopted for the support list -- i.e. no issues/messages about Alpha/Beta releases. The correct forum to discuss these issues is the developer list @ SourceForge. This issue, however, is about the v2.5 release which can be discussed in the support list -- the tracker is NOT a support forum. |
Commented by: vander clock stephane (arkadia) Seam, we are going off topic now, i not ask any support, i just report a bug ! If the fact that gfix or gbak can never finish and need to be manually killed to terminate is not a bug then close also, i agree with you that this bug are not necessary connected to gbak or gfix |
Commented by: vander clock stephane (arkadia) i thing we can connect this bug to the CORE3387 |
Submitted by: vander clock stephane (arkadia)
Hello,
it's already 3 days that we launch Gfix to do a sweep of the database, (gfix.exe -sweep) and it's still running (normally it's take an average of 1-2 hours)
Gfix use 0% of CPU usage (on client computer). on the server i don't see any gfix connection in the monitoring table
The firebird server never crash
Gfix.exe is not the release 26230, it's the original version from original 2.5 release is that can matter?
stephane
The text was updated successfully, but these errors were encountered: