Issue Details (XML | Word | Printable)

Key: CORE-3375
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: vander clock stephane
Votes: 0
Watchers: 3
Operations

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

Gfix (sweep) is running for 3 days now :(

Created: 05/Mar/11 08:56 AM   Updated: 23/Mar/11 08:01 AM
Component/s: GFIX
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Environment: Firebird 26230 (snapshot) - win64

Planning Status: Unspecified


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

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 05/Mar/11 09:18 AM
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.

vander clock stephane added a comment - 05/Mar/11 01:05 PM
> 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

Dmitry Yemanov added a comment - 05/Mar/11 02:22 PM
I'm afraid we can only guess here. This ticket cannot be resolved without a reproducible test case.

vander clock stephane added a comment - 05/Mar/11 03:03 PM
yes i understand, i will try to do a reproducible test case (cut the cable in the middle of the sweep ?)


Dmitry Yemanov added a comment - 05/Mar/11 03:16 PM
I cannot suggest anything as I have no clue what was the reason (network or something else).

vander clock stephane added a comment - 16/Mar/11 07:01 PM
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

Sean Leyne added a comment - 16/Mar/11 07:09 PM
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.

Dmitry Yemanov added a comment - 16/Mar/11 07:26 PM
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.

Sean Leyne added a comment - 16/Mar/11 07:45 PM
Based on the previous posting I suspect that the issue is there is a network problem

vander clock stephane added a comment - 16/Mar/11 08:53 PM
> 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 !

Sean Leyne added a comment - 18/Mar/11 03:44 PM
>> 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.

vander clock stephane added a comment - 19/Mar/11 04:51 PM - edited
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

vander clock stephane added a comment - 23/Mar/11 08:01 AM
i thing we can connect this bug to the CORE-3387