Looks like a geoserver WMS problem, best to take it to that forum.
Hi Paul/Sunny/Brent:
I think this is the same problem Brent Ownes was having a couple of weeks ago - we are hoping an update to the driver will fix things. Andrea/Chris Holmes had the details on the email list last week. Although I think they may have been waiting for brent to get back to them.
As I understand it several things are going on:
The Geotools2 connection pool handling is not returning connections to the pool when using Transaction.AUTO_COMMIT.
When brent foced his opperation to use a provided Transaction (and hense the same connection all the time) this problem went away. But he was still leaking memory (first statements, then result sets). The statement problem was fixed, we are hoping an update to a new jdbc driver will solve the result set leak..
So we have the following (can't remember the Jira bug tracker numbers):
- Geotools connection pooling problem (may also be driver)
- Geotools Result Set leak (we want to update to the new jdbc driver & test)
- GeoServer could keep a single Transaction data = new DefaultTransaction("geoserver") to make all its data requests.
This would hide Sunny's problem.
Cheers,
Jody
On Saturday, May 22, 2004, at 12:33 PM, Sunny Leung wrote:
Follow up onto my problem.
I notice each time a request to the WMS to the postgis datastore, a postgres process appear in the server ps list. Below is a capture from top:
2633 postgres 9 0 2100 2100 1700 S 0.0 0.2 0:00 postmaster
2635 postgres 9 0 2060 2060 1664 S 0.0 0.2 0:00 postmaster
2637 postgres 9 0 2092 2092 1668 S 0.0 0.2 0:00 postmaster
3842 postgres 9 0 5072 5072 3616 S 0.0 0.4 0:00 postmaster
3844 postgres 9 0 4852 4852 3596 S 0.0 0.4 0:00 postmaster
_______________________________________________
postgis-users mailing list
postgis-users@anonymised.com postgis-users Info Page
Alle 22:56, sabato 22 maggio 2004, Jody Garnett ha scritto:
Paul Ramsey wrote:
> Looks like a geoserver WMS problem, best to take it to that forum.
...
So we have the following (can't remember the Jira bug tracker numbers):
- Geotools connection pooling problem (may also be driver)
- Geotools Result Set leak (we want to update to the new jdbc driver &
test) - GeoServer could keep a single Transaction data = new
DefaultTransaction("geoserver") to make all its data requests.
This would hide Sunny's problem.
Also, lite renderer was not closing the feature readers.... Chris fixed this.
Did you try to reproduce the problem after this change?
Anyway, it seems the problem is more complex than I thought...
So we have the following (can't remember the Jira bug tracker numbers):
- Geotools connection pooling problem (may also be driver)
- Geotools Result Set leak (we want to update to the new jdbc driver &
test) - GeoServer could keep a single Transaction data = new
DefaultTransaction("geoserver") to make all its data requests.
This would hide Sunny's problem.
Also, lite renderer was not closing the feature readers.... Chris fixed this.
Did you try to reproduce the problem after this change? Anyway, it seems the problem is more complex than I thought...
Hi Andrea/Chris/Sunny:
Brent is quite busy gearing up for a project, I don't think you guys should wait on his feedback (or testing).
What would be nice to test is:
1) lite rendering patch from gt2
2) new postgres jdbc driver
3) postgis DataStore from fid-exp
We could try submitting a rc2 when fid-exp merge is done? Perhaps sunny would be willing to test an intern fix (1&2 above?). I could host such a beast on the vwfs.refractions.net website if needed.
>>So we have the following (can't remember the Jira bug tracker
numbers):
>>- Geotools connection pooling problem (may also be driver)
>>- Geotools Result Set leak (we want to update to the new jdbc
driver &
>>test) - GeoServer could keep a single Transaction data = new
>>DefaultTransaction("geoserver") to make all its data requests.
>>This would hide Sunny's problem.
>>
>>
>Also, lite renderer was not closing the feature readers.... Chris
fixed this.
>Did you try to reproduce the problem after this change?
>Anyway, it seems the problem is more complex than I thought...
>
>
Hi Andrea/Chris/Sunny:
Brent is quite busy gearing up for a project, I don't think you guys
should wait on his feedback (or testing).
What would be nice to test is:
1) lite rendering patch from gt2
2) new postgres jdbc driver
3) postgis DataStore from fid-exp
We could try submitting a rc2 when fid-exp merge is done? Perhaps
sunny
would be willing to test an intern fix (1&2 above?). I could host
such a
beast on the vwfs.refractions.net website if needed.
I would definitely be amenable for an rc2, in fact I was thinking of
doing it anyways, as I want to be sure that 1.2.0 is in perfect
condition, and there are obviously a few non-trivial fixes that need to
occur. I also may attempt to get a a binary release with jetty in time
for 1.2.0, and would want an rc to test it out a bit. So we can
release it on sourceforge. I can confirm that I did fix the biggest
problem, that every wms geoserver request opens a new connection. I
tested with my geoserver, it's committed to geotools svn, just needs to
be rolled into geoserver, as Andrea said. This should definitely fix
Sunny's wms problem. I'm unclear about the transaction auto commit
stuff in geoserver - I don't think we ever use auto commit
transactions, I think we always make a real transaction. So geotools
leaking those should not affect us. But I could be wrong about that,
and obviously it's not bad to fix, I just personally can't do the fix
since I don't really understand it. And actually I think I also put
code into geotools jdbc datastore to turn auto commit off if it is
result set forward only (which it is for the straight read requests).
This I found necessary to get us to not hold results in memory (and
this was recently confirmed by Andrea, that it is in fact needed).
best regards,
Chris
Cheers, Jody
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle
10g.
Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel