Thread: Resource temporarily unavailable
I have a servlet that generates a framesetpage. Each of the three frames on that framesetpage is also a link to a the same servlet, only with other parameters. The framesetpage has two parts: a topframe and a bottomframe. The bottomframe has again two parts: a leftframe and a rightframe. The topframe gets data from two tables, so does the left and the right. They each make a connection and a resultset for each (6 of them) query based on those tables. Additionally, they use a common table for metadata. After a few refreshes(three or four), he gives me an error: resource temporarily unavailable. How can I resolve this issue? Sometimes, I don't even have to refresh to get the error. The server my servlet is running under has a threadpool. But how do I prevent this error from occurring again? I don't need much, but I have to at least support 5 users at a time. I have tought about threading or connection pools, but I know very little about it. Any help is appreciated. Nico.
"Nico" <nicohmail-postgresql@yahoo.com> writes:
> topframe gets data from two tables, so does the left and the right. They
> each make a connection and a resultset for each (6 of them) query based on
> those tables. Additionally, they use a common table for metadata.
> After a few refreshes(three or four), he gives me an error: resource
> temporarily unavailable. How can I resolve this issue?
I think you're running into a processes-per-user limit, preventing the
postmaster from spawning more backend processes. You can and should
raise that limit (see your kernel documentation for details --- without
knowing what platform you're running on, I can't help). But you should
also rethink the strategy of opening a separate database connection for
each individual query. The overhead of doing things that way is
enormous.
regards, tom lane
The kernel is 2.4.21-15.0.2.ELsmp. Don't know which Linux distribution, since it's a remote server. So you think, I should keep the connection open the whole time until the servlet is finished, instead of opening and closing it everytime I need it? "Tom Lane" <tgl@sss.pgh.pa.us> schreef in bericht news:12612.1103945229@sss.pgh.pa.us... > "Nico" <nicohmail-postgresql@yahoo.com> writes: >> topframe gets data from two tables, so does the left and the right. They >> each make a connection and a resultset for each (6 of them) query based >> on >> those tables. Additionally, they use a common table for metadata. >> After a few refreshes(three or four), he gives me an error: resource >> temporarily unavailable. How can I resolve this issue? > > I think you're running into a processes-per-user limit, preventing the > postmaster from spawning more backend processes. You can and should > raise that limit (see your kernel documentation for details --- without > knowing what platform you're running on, I can't help). But you should > also rethink the strategy of opening a separate database connection for > each individual query. The overhead of doing things that way is > enormous. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend >
Nico wrote:
> The kernel is 2.4.21-15.0.2.ELsmp. Don't know which Linux distribution,
> since it's a remote server.
`cat /etc/issue` will usually tell you...
$ cat /etc/issue
Red Hat Linux release 8.0 (Psyche)
Kernel \r on an \m
that sounds like Redhat Enterprise 3 to me, but thats a wild guess.
I don't have enough access to do that. I have no control over the remote server. But I solved myself: I forgot to close one of my connections. I no longer have the problem. Thanks anyway. "John R Pierce" <pierce@hogranch.com> schreef in bericht news:41CE004A.9080709@hogranch.com... > Nico wrote: >> The kernel is 2.4.21-15.0.2.ELsmp. Don't know which Linux distribution, >> since it's a remote server. > > `cat /etc/issue` will usually tell you... > > $ cat /etc/issue > Red Hat Linux release 8.0 (Psyche) > Kernel \r on an \m > > that sounds like Redhat Enterprise 3 to me, but thats a wild guess. > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org >