Skip to content
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

Open
firebird-automations opened this issue Mar 5, 2011 · 13 comments
Open

Gfix (sweep) is running for 3 days now :( [CORE3375] #3741

firebird-automations opened this issue Mar 5, 2011 · 13 comments

Comments

@firebird-automations
Copy link
Collaborator

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

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

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

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

I'm afraid we can only guess here. This ticket cannot be resolved without a reproducible test case.

@firebird-automations
Copy link
Collaborator Author

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 ?)

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

I cannot suggest anything as I have no clue what was the reason (network or something else).

@firebird-automations
Copy link
Collaborator Author

Commented by: vander clock stephane (arkadia)

now i have the same probleme with gback :(
their is no gbak.exe in the MON$ table
and the gback command command tool is block on
gbak:1760000 records written

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

Based on the previous posting I suspect that the issue is there is a network problem

@firebird-automations
Copy link
Collaborator Author

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) !
2. i don't thing about a network problem because in the FB 2.5 original version i have 10 times more problem like this than in the 2.5 26230 beta version and the network is the same !
3. on the "same network' architecture (but different server) we have other database like mysql and we never (of the never) have any problem (but they are not use so heavily as we use firebird i agree)
4. in this "frozen" bug kind, we see in my other bug report (i open another because was not connected to gfix or gback but to my own client) have one frozen on the client side and in the server side we can see in the $mon table the connection... what kind of network problem can do this ?

all of this make me more thinging about a deadlock somewhere (or a badly newtork protocal) that the simple network probleme ...
anyway, i repeat, "even" if it's was a network probleme, it's not normal that the client stay connected for undefinite time and not stop with a network error exception ...

> 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 !

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

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
this tracker with "not a bug"

also, i agree with you that this bug are not necessary connected to gbak or gfix
but with the client library and network protocol

@firebird-automations
Copy link
Collaborator Author

Commented by: vander clock stephane (arkadia)

i thing we can connect this bug to the CORE3387

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant