Sometimes, without a clear logic I get the compleste crash of Tomcat
after performing Geoserver requests (i.e map preview, or wfs-t demo).
The last line that I find in catalina.log is:
Java HotSpot(TM) 64-Bit Server VM warning: Exception
java.lang.OutOfMemoryError occurred dispatching signal SIGTERM to
handler- the VM may need to be forcibly terminated
Thist make me think it's a bug related to the JVM. Something similar
is reported for other apps (ie Eclipse).
It happened frequently the first times, now (as I'm writing...) it seems stable.
You should read about increasing heap space in JVM, and also have a look at the geoserver in production enviroment page that is found at geoserver.org somewhere.
Aside from a a too small JVM heap, memory leaks has been reported (not sure how common). In this case an automatic JVM restart is the only workaround until the memory leaks are fixed.
/Björn
On Thu, Oct 2, 2008 at 3:36 PM, G. Allegri <giohappy@…84…> wrote:
I’ve found problems deploying the following environment:
Sometimes, without a clear logic I get the compleste crash of Tomcat
after performing Geoserver requests (i.e map preview, or wfs-t demo).
The last line that I find in catalina.log is:
Java HotSpot™ 64-Bit Server VM warning: Exception
java.lang.OutOfMemoryError occurred dispatching signal SIGTERM to
handler- the VM may need to be forcibly terminated
Thist make me think it’s a bug related to the JVM. Something similar
is reported for other apps (ie Eclipse).
It happened frequently the first times, now (as I’m writing…) it seems stable.
Has anybody faced this before?
Any advice?
Thanks, Giovanni
This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
What's the best way to set the JVM settings?
I set it with:
export CATALINA_OPTS="..."
inside the Tomcat startup script, but probably there's a cleaner way...
2008/10/2 Björn Harrtell <bjorn.harrtell@anonymised.com>:
Out of memory is pretty clear logic to me
You should read about increasing heap space in JVM, and also have a look at
the geoserver in production enviroment page that is found at geoserver.org
somewhere.
Aside from a a too small JVM heap, memory leaks has been reported (not sure
how common). In this case an automatic JVM restart is the only workaround
until the memory leaks are fixed.
/Björn
On Thu, Oct 2, 2008 at 3:36 PM, G. Allegri <giohappy@anonymised.com> wrote:
I've found problems deploying the following environment:
Sometimes, without a clear logic I get the compleste crash of Tomcat
after performing Geoserver requests (i.e map preview, or wfs-t demo).
The last line that I find in catalina.log is:
Java HotSpot(TM) 64-Bit Server VM warning: Exception
java.lang.OutOfMemoryError occurred dispatching signal SIGTERM to
handler- the VM may need to be forcibly terminated
Thist make me think it's a bug related to the JVM. Something similar
is reported for other apps (ie Eclipse).
It happened frequently the first times, now (as I'm writing...) it seems
stable.
Has anybody faced this before?
Any advice?
Thanks, Giovanni
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Hi,
We're running a similar config (except ew run geoserver 1.6.5) and we seem to have the same problem.
Our temporary "solution" was to bump up memory settings of the JVM to slightly over 2GB
We also has geowebcache installed as a separate webapp in the same tomcat and when we ran our frontend (OpenLayers) to geowebcache tomcat starts eating CPU (all 8 cores of them, sic!) untill it crashes. It could be that geowebcache fetches tiles outside the request that actually escalates memory consumption by orders of magnitude.
I'm not certain, but I think that geowebcache is integration into geoserver in 1.7 as well. Are you using geowebcache functionality from within geoserver?
To conclude, you are not alone in your setup.
Exactly where the problem is I haven't had time to dwelve into yet.
Regards,
Per-Olof
G. Allegri skrev:
What's the best way to set the JVM settings?
I set it with:
export CATALINA_OPTS="..."
inside the Tomcat startup script, but probably there's a cleaner way...
2008/10/2 Björn Harrtell <bjorn.harrtell@anonymised.com>:
Out of memory is pretty clear logic to me
You should read about increasing heap space in JVM, and also have a look at
the geoserver in production enviroment page that is found at geoserver.org
somewhere.
Aside from a a too small JVM heap, memory leaks has been reported (not sure
how common). In this case an automatic JVM restart is the only workaround
until the memory leaks are fixed.
/Björn
On Thu, Oct 2, 2008 at 3:36 PM, G. Allegri <giohappy@anonymised.com> wrote:
I've found problems deploying the following environment:
Sometimes, without a clear logic I get the compleste crash of Tomcat
after performing Geoserver requests (i.e map preview, or wfs-t demo).
The last line that I find in catalina.log is:
Java HotSpot(TM) 64-Bit Server VM warning: Exception
java.lang.OutOfMemoryError occurred dispatching signal SIGTERM to
handler- the VM may need to be forcibly terminated
Thist make me think it's a bug related to the JVM. Something similar
is reported for other apps (ie Eclipse).
It happened frequently the first times, now (as I'm writing...) it seems
stable.
Has anybody faced this before?
Any advice?
Thanks, Giovanni
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
In which context are you getting OOM. Sounds like a memory leak. Is it after a while of using the server, or does memory spike right away when you load up GeoServer?
If it is the former then its most likely a memory leak. It would be helpful if you could report the type of requests you are making (WMS vs WFS), (GET vs POST), etc...
With WFS there is a well known issue with a memory leak which we will be fixing soon on 1.7.x.
-Justin
Per-Olof Norén wrote:
Hi,
We're running a similar config (except ew run geoserver 1.6.5) and we seem to have the same problem.
Our temporary "solution" was to bump up memory settings of the JVM to slightly over 2GB
We also has geowebcache installed as a separate webapp in the same tomcat and when we ran our frontend (OpenLayers) to geowebcache tomcat starts eating CPU (all 8 cores of them, sic!) untill it crashes. It could be that geowebcache fetches tiles outside the request that actually escalates memory consumption by orders of magnitude.
I'm not certain, but I think that geowebcache is integration into geoserver in 1.7 as well. Are you using geowebcache functionality from within geoserver?
To conclude, you are not alone in your setup.
Exactly where the problem is I haven't had time to dwelve into yet.
Regards,
Per-Olof
G. Allegri skrev:
What's the best way to set the JVM settings?
I set it with:
export CATALINA_OPTS="..."
inside the Tomcat startup script, but probably there's a cleaner way...
2008/10/2 Björn Harrtell <bjorn.harrtell@anonymised.com>:
Out of memory is pretty clear logic to me
You should read about increasing heap space in JVM, and also have a look at
the geoserver in production enviroment page that is found at geoserver.org
somewhere.
Aside from a a too small JVM heap, memory leaks has been reported (not sure
how common). In this case an automatic JVM restart is the only workaround
until the memory leaks are fixed.
/Björn
On Thu, Oct 2, 2008 at 3:36 PM, G. Allegri <giohappy@anonymised.com> wrote:
I've found problems deploying the following environment:
Sometimes, without a clear logic I get the compleste crash of Tomcat
after performing Geoserver requests (i.e map preview, or wfs-t demo).
The last line that I find in catalina.log is:
Java HotSpot(TM) 64-Bit Server VM warning: Exception
java.lang.OutOfMemoryError occurred dispatching signal SIGTERM to
handler- the VM may need to be forcibly terminated
Thist make me think it's a bug related to the JVM. Something similar
is reported for other apps (ie Eclipse).
It happened frequently the first times, now (as I'm writing...) it seems
stable.
Has anybody faced this before?
Any advice?
Thanks, Giovanni
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
this was reported [1] and fixed [2], I strongly encourage everyone to update.
Please do file bug reports when you see such behavior, even if you don't have time to dig very far into it. It was a pretty elusive bug, I was very lucky someone ran into an easily reproducible example.
We also has geowebcache installed as a separate webapp in the same tomcat and when we ran our frontend (OpenLayers) to geowebcache tomcat starts eating CPU (all 8 cores of them, sic!) untill it crashes. It could be that geowebcache fetches tiles outside the request that actually escalates memory consumption by orders of magnitude.
I'm not certain, but I think that geowebcache is integration into geoserver in 1.7 as well. Are you using geowebcache functionality from within geoserver?
To conclude, you are not alone in your setup.
Exactly where the problem is I haven't had time to dwelve into yet.
Regards,
Per-Olof
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
I think I've solved my problems installing more RAM on the server and
giving 256 MB to the JVM (through CATALINA_OPT settings).
Anyway the peaks of memory usage came during multiple accesses to the
wfs-t demo...
I don't have gwc instlalled at them moment. I will let you know as
soon as I setup it.
Thanks
2008/10/4 Arne Kepp <ak@anonymised.com>:
Hi,
this was reported [1] and fixed [2], I strongly encourage everyone to
update.
Please do file bug reports when you see such behavior, even if you don't
have time to dig very far into it. It was a pretty elusive bug, I was very
lucky someone ran into an easily reproducible example.
We also has geowebcache installed as a separate webapp in the same tomcat
and when we ran our frontend (OpenLayers) to geowebcache tomcat starts
eating CPU (all 8 cores of them, sic!) untill it crashes. It could be that
geowebcache fetches tiles outside the request that actually escalates memory
consumption by orders of magnitude.
I'm not certain, but I think that geowebcache is integration into
geoserver in 1.7 as well. Are you using geowebcache functionality from
within geoserver?
To conclude, you are not alone in your setup.
Exactly where the problem is I haven't had time to dwelve into yet.
Regards,
Per-Olof
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
256 Mb can IMO still be pretty low for geoserver, depending of course on how large images/datasets is used and the server load.
/Björn
On Sat, Oct 4, 2008 at 2:44 PM, G. Allegri <giohappy@…84…> wrote:
I think I’ve solved my problems installing more RAM on the server and
giving 256 MB to the JVM (through CATALINA_OPT settings).
Anyway the peaks of memory usage came during multiple accesses to the
wfs-t demo…
I don’t have gwc instlalled at them moment. I will let you know as
soon as I setup it.
this was reported [1] and fixed [2], I strongly encourage everyone to
update.
Please do file bug reports when you see such behavior, even if you don’t
have time to dig very far into it. It was a pretty elusive bug, I was very
lucky someone ran into an easily reproducible example.
We also has geowebcache installed as a separate webapp in the same tomcat
and when we ran our frontend (OpenLayers) to geowebcache tomcat starts
eating CPU (all 8 cores of them, sic!) untill it crashes. It could be that
geowebcache fetches tiles outside the request that actually escalates memory
consumption by orders of magnitude.
I’m not certain, but I think that geowebcache is integration into
geoserver in 1.7 as well. Are you using geowebcache functionality from
within geoserver?
To conclude, you are not alone in your setup.
Exactly where the problem is I haven’t had time to dwelve into yet.
Regards,
Per-Olof
–
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
A the moment it's just a shared development server, so it's not a real
production environment... it's a VS with not so much resources, so I
can't ask it to much!
2008/10/4 Björn Harrtell <bjorn.harrtell@anonymised.com>:
256 Mb can IMO still be pretty low for geoserver, depending of course on how
large images/datasets is used and the server load.
/Björn
On Sat, Oct 4, 2008 at 2:44 PM, G. Allegri <giohappy@anonymised.com> wrote:
I think I've solved my problems installing more RAM on the server and
giving 256 MB to the JVM (through CATALINA_OPT settings).
Anyway the peaks of memory usage came during multiple accesses to the
wfs-t demo...
I don't have gwc instlalled at them moment. I will let you know as
soon as I setup it.
Thanks
2008/10/4 Arne Kepp <ak@anonymised.com>:
> Hi,
>
> this was reported [1] and fixed [2], I strongly encourage everyone to
> update.
>
> Please do file bug reports when you see such behavior, even if you don't
> have time to dig very far into it. It was a pretty elusive bug, I was
> very
> lucky someone ran into an easily reproducible example.
>
> -Arne
>
> 1: http://geowebcache.org/trac/ticket/51
> 2:
>
> http://www.nabble.com/Updated-gwc-plugin-for-GeoServer-1.7.0-RC3-and-1.6.5-to19745058.html
>
> Per-Olof Norén wrote:
>>
>> We also has geowebcache installed as a separate webapp in the same
>> tomcat
>> and when we ran our frontend (OpenLayers) to geowebcache tomcat starts
>> eating CPU (all 8 cores of them, sic!) untill it crashes. It could be
>> that
>> geowebcache fetches tiles outside the request that actually escalates
>> memory
>> consumption by orders of magnitude.
>>
>> I'm not certain, but I think that geowebcache is integration into
>> geoserver in 1.7 as well. Are you using geowebcache functionality from
>> within geoserver?
>>
>> To conclude, you are not alone in your setup.
>> Exactly where the problem is I haven't had time to dwelve into yet.
>>
>> Regards,
>> Per-Olof
>>
>
> --
> Arne Kepp
> OpenGeo - http://opengeo.org
> Expert service straight from the developers
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
I think I've solved my problems installing more RAM on the server and
giving 256 MB to the JVM (through CATALINA_OPT settings).
Anyway the peaks of memory usage came during multiple accesses to the
wfs-t demo...
If you're doing WFS-T we have a known memory leak that has been fixed
just recently and will be included in the next 1.7.0 RC (not sure the
bug fix will be back ported to 1.6.x, it depends on whether we'll do
another final release of 1.6.x or not, 1.6.5 was meant to be the last
one, no developer is still active on that branch).
Great Andrea. I'm using RC3, so I suppose you're referring to RC4 for bugfix...
2008/10/4 Andrea Aime <aaime@anonymised.com>:
G. Allegri wrote:
I think I've solved my problems installing more RAM on the server and
giving 256 MB to the JVM (through CATALINA_OPT settings).
Anyway the peaks of memory usage came during multiple accesses to the
wfs-t demo...
If you're doing WFS-T we have a known memory leak that has been fixed
just recently and will be included in the next 1.7.0 RC (not sure the
bug fix will be back ported to 1.6.x, it depends on whether we'll do
another final release of 1.6.x or not, 1.6.5 was meant to be the last
one, no developer is still active on that branch).
Hi,
We're running a similar config (except ew run geoserver 1.6.5) and we seem to have the same problem.
Our temporary "solution" was to bump up memory settings of the JVM to slightly over 2GB
We also has geowebcache installed as a separate webapp in the same tomcat and when we ran our frontend (OpenLayers) to geowebcache tomcat starts eating CPU (all 8 cores of them, sic!) untill it crashes. It could be that geowebcache fetches tiles outside the request that actually escalates memory consumption by orders of magnitude.
Mumble, wondering, what is the meta tiling factor you're using
for the tile cache? If it's big (e.g. > 10) it will trigger GetMaps
that do require a lot of memory to be processed due to the need of
representing all the pixels of the output image in 4byte color
depth.
I'm not certain, but I think that geowebcache is integration into geoserver in 1.7 as well. Are you using geowebcache functionality from within geoserver?
Actually I have been running some benchmarks with GWC 1.0beta integrated
in geoServer, using the default meta tiling factor of 4, and did not
notice memory leaks even after thousands of requests... I can try
to push things a little further and go into the hundred of thousands,
and see if there is any memory leak.
Hi,
We're running a similar config (except ew run geoserver 1.6.5) and we seem to have the same problem.
Our temporary "solution" was to bump up memory settings of the JVM to slightly over 2GB
We also has geowebcache installed as a separate webapp in the same tomcat and when we ran our frontend (OpenLayers) to geowebcache tomcat starts eating CPU (all 8 cores of them, sic!) untill it crashes. It could be that geowebcache fetches tiles outside the request that actually escalates memory consumption by orders of magnitude.
Mumble, wondering, what is the meta tiling factor you're using
for the tile cache? If it's big (e.g. > 10) it will trigger GetMaps
that do require a lot of memory to be processed due to the need of
representing all the pixels of the output image in 4byte color
depth.
Were using the default value.
I'm not certain, but I think that geowebcache is integration into geoserver in 1.7 as well. Are you using geowebcache functionality from within geoserver?
Actually I have been running some benchmarks with GWC 1.0beta integrated
in geoServer, using the default meta tiling factor of 4, and did not
notice memory leaks even after thousands of requests... I can try
to push things a little further and go into the hundred of thousands,
and see if there is any memory leak.
I just tried installing geowebcache beta1, as Arne Kepp recommended and this solved our CPU usage problem.
Our OL configuration resulted in an odd resolution, and what i thought was swapping was actually a "busy-loop" searching for a suitable extent. (http://geowebcache.org/trac/changeset/403)
We are also using WFS so I suppose the memory errors we saw in the logs was a result of a known problem with WFS and a couple of requests for all 26K features of one of our featuretypes.
So, I see no need to trace memory leeks for my specific problem here.
Thanx for quick replies and code fixes.
I can understand that you need to abandon 1.6 but I definitely think serious bugs are worth fixing, since the 1.6 series has been very solid. Going to the first stable version of 1.7.0 I think involves more risk than a minor upgrade of 1.6
Justin mentioned releasing 1.6.6 in another thread regarding another bug, a bug that seem minor though. Memory leaks in WFS-T is, at least for us, a major one…and if it is possible to fix it for 1.6.6 that would be wonderful news
/Björn
On Sat, Oct 4, 2008 at 5:54 PM, Andrea Aime <aaime@…1671…> wrote:
G. Allegri wrote:
I think I’ve solved my problems installing more RAM on the server and
giving 256 MB to the JVM (through CATALINA_OPT settings).
Anyway the peaks of memory usage came during multiple accesses to the
wfs-t demo…
If you’re doing WFS-T we have a known memory leak that has been fixed
just recently and will be included in the next 1.7.0 RC (not sure the
bug fix will be back ported to 1.6.x, it depends on whether we’ll do
another final release of 1.6.x or not, 1.6.5 was meant to be the last
one, no developer is still active on that branch).
Cheers
Andrae
This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
I can understand that you need to abandon 1.6 but I definitely think serious bugs are worth fixing, since the 1.6 series has been very solid. Going to the first stable version of 1.7.0 I think involves more risk than a minor upgrade of 1.6
Justin mentioned releasing 1.6.6 in another thread regarding another bug, a bug that seem minor though. Memory leaks in WFS-T is, at least for us, a major one...and if it is possible to fix it for 1.6.6 that would be wonderful news
The fix for the OOM is not trivial, it's up to Justin to check
whether the fix is back-portable and how difficult that is.
CC'ing him, let's see how this is.
Since we are releasing 1.6.6 it should be relatively easy to backport the patch that was recently applied to 1.7.x to fix a similar problem. However I am not convinced that is the only issue going on here.
Regardless, i have created a jira issue for the patch:
Could the folks seeing OOM issues with WFS sign up as watchers on the issue and perhaps be willing to try out a nightly build after the patch is applied?
-Justin
Andrea Aime wrote:
Björn Harrtell wrote:
I can understand that you need to abandon 1.6 but I definitely think serious bugs are worth fixing, since the 1.6 series has been very solid. Going to the first stable version of 1.7.0 I think involves more risk than a minor upgrade of 1.6
Justin mentioned releasing 1.6.6 in another thread regarding another bug, a bug that seem minor though. Memory leaks in WFS-T is, at least for us, a major one...and if it is possible to fix it for 1.6.6 that would be wonderful news
The fix for the OOM is not trivial, it's up to Justin to check
whether the fix is back-portable and how difficult that is.
CC'ing him, let's see how this is.
Cheers
Andrea
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Cia Justin, what's the timeframe you are thinking of for 1.6.6, I
might want to try and backport the raster symbolizer as well. After
all, the first time I implemented it it was for gt 2.4.x.
Simone.
On Mon, Oct 6, 2008 at 12:13 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hi all,
Since we are releasing 1.6.6 it should be relatively easy to backport
the patch that was recently applied to 1.7.x to fix a similar problem.
However I am not convinced that is the only issue going on here.
Regardless, i have created a jira issue for the patch:
Could the folks seeing OOM issues with WFS sign up as watchers on the
issue and perhaps be willing to try out a nightly build after the patch
is applied?
-Justin
Andrea Aime wrote:
Björn Harrtell wrote:
I can understand that you need to abandon 1.6 but I definitely think
serious bugs are worth fixing, since the 1.6 series has been very solid.
Going to the first stable version of 1.7.0 I think involves more risk
than a minor upgrade of 1.6
Justin mentioned releasing 1.6.6 in another thread regarding another
bug, a bug that seem minor though. Memory leaks in WFS-T is, at least
for us, a major one...and if it is possible to fix it for 1.6.6 that
would be wonderful news
The fix for the OOM is not trivial, it's up to Justin to check
whether the fix is back-portable and how difficult that is.
CC'ing him, let's see how this is.
Cheers
Andrea
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
I don't think we have a hard deadline for when to release. Currently in jira i have it scheduled for 2 weeks from now, but I think we can wait on you guys... and when it works for you.
There are some users waiting on fixes but I think we can probably hold them off with nightly builds in the meantime.
So I bounce the question back to you :). When will a release work best for you?
-Justin
Simone Giannecchini wrote:
Cia Justin, what's the timeframe you are thinking of for 1.6.6, I
might want to try and backport the raster symbolizer as well. After
all, the first time I implemented it it was for gt 2.4.x.
Simone.
On Mon, Oct 6, 2008 at 12:13 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hi all,
Since we are releasing 1.6.6 it should be relatively easy to backport
the patch that was recently applied to 1.7.x to fix a similar problem.
However I am not convinced that is the only issue going on here.
Regardless, i have created a jira issue for the patch:
Could the folks seeing OOM issues with WFS sign up as watchers on the
issue and perhaps be willing to try out a nightly build after the patch
is applied?
-Justin
Andrea Aime wrote:
Björn Harrtell wrote:
I can understand that you need to abandon 1.6 but I definitely think
serious bugs are worth fixing, since the 1.6 series has been very solid..
Going to the first stable version of 1.7.0 I think involves more risk
than a minor upgrade of 1.6
Justin mentioned releasing 1.6.6 in another thread regarding another
bug, a bug that seem minor though. Memory leaks in WFS-T is, at least
for us, a major one...and if it is possible to fix it for 1.6.6 that
would be wonderful news
The fix for the OOM is not trivial, it's up to Justin to check
whether the fix is back-portable and how difficult that is.
CC'ing him, let's see how this is.
Cheers
Andrea
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Ciao Justin,
I do no think we will have time for this release before November,
therefore I guess on this end the deadline could be posed around the
first week of November. I would really like to integrate the
RasterSymbolizer as well, and that could take me a few days.
Simone.
On Mon, Oct 6, 2008 at 12:35 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Ciao Simone,
I don't think we have a hard deadline for when to release. Currently in jira
i have it scheduled for 2 weeks from now, but I think we can wait on you
guys... and when it works for you.
There are some users waiting on fixes but I think we can probably hold them
off with nightly builds in the meantime.
So I bounce the question back to you :). When will a release work best for
you?
-Justin
Simone Giannecchini wrote:
Cia Justin, what's the timeframe you are thinking of for 1.6.6, I
might want to try and backport the raster symbolizer as well. After
all, the first time I implemented it it was for gt 2.4.x.
Simone.
On Mon, Oct 6, 2008 at 12:13 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:
Hi all,
Since we are releasing 1.6.6 it should be relatively easy to backport
the patch that was recently applied to 1.7.x to fix a similar problem.
However I am not convinced that is the only issue going on here.
Regardless, i have created a jira issue for the patch:
Could the folks seeing OOM issues with WFS sign up as watchers on the
issue and perhaps be willing to try out a nightly build after the patch
is applied?
-Justin
Andrea Aime wrote:
Björn Harrtell wrote:
I can understand that you need to abandon 1.6 but I definitely think
serious bugs are worth fixing, since the 1.6 series has been very
solid..
Going to the first stable version of 1.7.0 I think involves more risk
than a minor upgrade of 1.6
Justin mentioned releasing 1.6.6 in another thread regarding another
bug, a bug that seem minor though. Memory leaks in WFS-T is, at least
for us, a major one...and if it is possible to fix it for 1.6.6 that
would be wonderful news
The fix for the OOM is not trivial, it's up to Justin to check
whether the fix is back-portable and how difficult that is.
CC'ing him, let's see how this is.
Cheers
Andrea
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
