Subject | allocl_global: Event table space exhausted |
---|---|
Author | unordained |
Post date | 2005-09-27T06:18:12Z |
kronos (Server) Mon Sep 26 23:21:09 2005
alloc_global: Event table space exhausted
I'm seeing this in my logs tonight, right before the db server crashes. SuperServer 1.5.1 on Linux
(Slackware) on x86 hardware. I haven't tweaked my config files for FB at all.
I'm using AJAX (XMLHttpRequest) to wait for events on the server, and each page may register, say,
6 listeners, each interested in 6 or so events. It doesn't take much more than that, going all at
once, to crash firebird. I don't have exact numbers, sorry. I can probably blame myself for making
my C++ code 'simple' -- to get around the 15-events-per-block limit, without having to think about
it, I used one event request block per event request, rather than filling them up. So if that
matters, there's that info. (30 to 40 or thereabouts request blocks, total, from various processes.)
(Guardian has been so kind as to restart it for me, partially hiding the problem. I could -not- for
the life of me figure out why my wait-for-event process was returning an error sometimes, telling
me it couldn't connect to the server.)
I saw one related post on sourceforge's copy of firebird-devel ... anyone have ideas?
Admittedly, my idea is probably bad from the get-go -- too many processes running at once on the
server, probably wouldn't scale well, etc. And it's an off-hours (but sort-of-for-work) project,
and not critical. I can handle events via an event-logging table, with a "polling" approach rather
than my current "selecting" one. But crashes are crashes ... I figure someone ought to know about
it.
-Philip
alloc_global: Event table space exhausted
I'm seeing this in my logs tonight, right before the db server crashes. SuperServer 1.5.1 on Linux
(Slackware) on x86 hardware. I haven't tweaked my config files for FB at all.
I'm using AJAX (XMLHttpRequest) to wait for events on the server, and each page may register, say,
6 listeners, each interested in 6 or so events. It doesn't take much more than that, going all at
once, to crash firebird. I don't have exact numbers, sorry. I can probably blame myself for making
my C++ code 'simple' -- to get around the 15-events-per-block limit, without having to think about
it, I used one event request block per event request, rather than filling them up. So if that
matters, there's that info. (30 to 40 or thereabouts request blocks, total, from various processes.)
(Guardian has been so kind as to restart it for me, partially hiding the problem. I could -not- for
the life of me figure out why my wait-for-event process was returning an error sometimes, telling
me it couldn't connect to the server.)
I saw one related post on sourceforge's copy of firebird-devel ... anyone have ideas?
Admittedly, my idea is probably bad from the get-go -- too many processes running at once on the
server, probably wouldn't scale well, etc. And it's an off-hours (but sort-of-for-work) project,
and not critical. I can handle events via an event-logging table, with a "polling" approach rather
than my current "selecting" one. But crashes are crashes ... I figure someone ought to know about
it.
-Philip