| Subject | Re: [firebird-support] fb_inet_server hangs? |
|---|---|
| Author | Helen Borrie |
| Post date | 2012-03-22T19:46:46Z |
At 07:57 AM 23/03/2012, Kjell Rilbe wrote:
With Classic, the first instance of fb_inet_server is a listener that can't "terminate abnormally" due to misbehaving clients, since it doesn't have clients. Its job is to spawn an entire copy of the server process for each client connection. A client process can crash if the client end misbehaves or if the network connection dies unexpectedly.
If you have Guardian running, it will try to revive *that* process; but of course the client end is dead so the old handle is not associated with any client socket any more. The revived process becomes a "ghost connection" that is unused but nevertheless holds on to the old page cache and of course eats RAM for itself.
The ghost processes are harmless in themselves but, because each one is holding resources, time and circumstance will eventually cause resources to run out as the ghosts proliferate. I recall testing and proving the theory myself with v.1.5 and 2.0 Classic on NT4 and XP Pro. This issue has been around as long as Firebird has had a CS available for Windows. I don't know if the fix (core-2356) that Vlad backported to v.2.1.4 addressed it. I would guess that it's been a non-issue now for a long time, since installation notes for 2.0 and 2.1 quite clearly advise against trying to run Guardian with Classic and, AFAIR, it has been "off" by default for Classic in the Windows installers since the 2.x era.
./heLen
>Helen Borrie skriver:The Guardian should not be installed at all for Classic. It was introduced for SS back in the depths of time when nt3/4, Win 3.1/95/98 were the order of the day and Borland had abandoned Classic. Even SS running as a service on XP or higher doesn't need it, as services in XP-onward can be configured to attempt a restart if fbserver.exe ends abnormally.
>>
>> At 04:02 AM 23/03/2012, Kjell Rilbe wrote:
>> >Thomas Steinmaurer skriver:
>> >>
>> >> > On occasion, it seems that one of the fb_inet_server processes hangs.
>> >> > Are there any known issues that would cause a hang?
>> >>
>> >> Yes, that can happen from time to time. As you are on 2.1.3, e.g. the
>> >> list of fixed bugs in 2.1.4 show some evidence that things do improve
>> >> with each (sub)-release.
>> >>
>>
>> And don't forget to keep Guardian right out of the picture.
>>
>
>What's that supposed to mean? The guardian was running as usual I believe...
With Classic, the first instance of fb_inet_server is a listener that can't "terminate abnormally" due to misbehaving clients, since it doesn't have clients. Its job is to spawn an entire copy of the server process for each client connection. A client process can crash if the client end misbehaves or if the network connection dies unexpectedly.
If you have Guardian running, it will try to revive *that* process; but of course the client end is dead so the old handle is not associated with any client socket any more. The revived process becomes a "ghost connection" that is unused but nevertheless holds on to the old page cache and of course eats RAM for itself.
The ghost processes are harmless in themselves but, because each one is holding resources, time and circumstance will eventually cause resources to run out as the ghosts proliferate. I recall testing and proving the theory myself with v.1.5 and 2.0 Classic on NT4 and XP Pro. This issue has been around as long as Firebird has had a CS available for Windows. I don't know if the fix (core-2356) that Vlad backported to v.2.1.4 addressed it. I would guess that it's been a non-issue now for a long time, since installation notes for 2.0 and 2.1 quite clearly advise against trying to run Guardian with Classic and, AFAIR, it has been "off" by default for Classic in the Windows installers since the 2.x era.
./heLen