Subject | 1.5.1 CS for Linux with xinetd |
---|---|
Author | David Montgomery |
Post date | 2004-10-05T21:39:16Z |
Hi everyone,
Until recently, we had been running FB 1.5.1 on a Windows machine, but
now we're running in a Linux environment.
One puzzling behavior I've encountered is related to leaving
connections to the server open unintentionally (which I discovered
from a bug in one of my apps) which seems to create an entry in 'ps
-aux' like:
fbdata 10051 0.0 0.6 89108 7088 ? S 14:12 0:00
fb_inet_server
After a while my buggy application managed to get xinetd to restart
the gds_db service for too many open connections. I would expect
xinetd to act this way, BUT...when xinetd allows client connections
again, ALL of the previous connections remain open on the server (i.e.
the same 'fb_inet_server' entries remain in the process list). I
would expect the existing connetions to get dropped/killed when this
happens.
Does anyone have any insight into how the server should behave with
abaondoned connections? For the life of me, I can't remember if
Firebird automatically cleans these up after a certain period of
inactivity.
Another question of interest for me: does anyone have any metric of
the maximum total number of concurrent connections are supported by CS
in Linux.
Best Regards,
David Montgomery
Until recently, we had been running FB 1.5.1 on a Windows machine, but
now we're running in a Linux environment.
One puzzling behavior I've encountered is related to leaving
connections to the server open unintentionally (which I discovered
from a bug in one of my apps) which seems to create an entry in 'ps
-aux' like:
fbdata 10051 0.0 0.6 89108 7088 ? S 14:12 0:00
fb_inet_server
After a while my buggy application managed to get xinetd to restart
the gds_db service for too many open connections. I would expect
xinetd to act this way, BUT...when xinetd allows client connections
again, ALL of the previous connections remain open on the server (i.e.
the same 'fb_inet_server' entries remain in the process list). I
would expect the existing connetions to get dropped/killed when this
happens.
Does anyone have any insight into how the server should behave with
abaondoned connections? For the life of me, I can't remember if
Firebird automatically cleans these up after a certain period of
inactivity.
Another question of interest for me: does anyone have any metric of
the maximum total number of concurrent connections are supported by CS
in Linux.
Best Regards,
David Montgomery