Opengeo is migrating the existing hudson installation to a new server. I am currently setting up the new server as we speak.
In order to smoothly transition and not loose any build history I plan to take the old hudson instance down, rsync all the build directories to the new server, and bring the new instance up.
So unless anyone has any objections i plan to do that tonight... sometime around probably 6 MDT which is about midnight UTC.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On 21/07/2010, at 2:55 AM, Justin Deoliveira wrote:
Hi all,
Please excuse the cross post.
Opengeo is migrating the existing hudson installation to a new server. I
am currently setting up the new server as we speak.
In order to smoothly transition and not loose any build history I plan
to take the old hudson instance down, rsync all the build directories to
the new server, and bring the new instance up.
So unless anyone has any objections i plan to do that tonight...
sometime around probably 6 MDT which is about midnight UTC.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Unfortunately it did not go so well. I could not get one build out due to memory errors. Which seem to happen only in the app-schema module. Ben any ideas there? Have you ever seen this. I have replicated memory settings from the other hudson so it should be the same.
Anyways, I will continue on debugging these issues and will have to plan the migration for something later this week hopefully.
-Justin
On 10-07-20 4:36 PM, Jody Garnett wrote:
Thanks Justin; good luck in the migration.
Jody
On 21/07/2010, at 2:55 AM, Justin Deoliveira wrote:
Hi all,
Please excuse the cross post.
Opengeo is migrating the existing hudson installation to a new server. I
am currently setting up the new server as we speak.
In order to smoothly transition and not loose any build history I plan
to take the old hudson instance down, rsync all the build directories to
the new server, and bring the new instance up.
So unless anyone has any objections i plan to do that tonight...
sometime around probably 6 MDT which is about midnight UTC.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Unfortunately it did not go so well. I could not get one build out due to memory errors. Which seem to happen only in the app-schema module. Ben any ideas there? Have you ever seen this. I have replicated memory settings from the other hudson so it should be the same.
Anyways, I will continue on debugging these issues and will have to plan the migration for something later this week hopefully.
Interesting. Are we switching from a 32bit host to a 64bit one?
It may be relevant as object pointers in 64bit use twice as much
space, so if we have a slew of small objects the increase can
be significant.
Modern JVM should have a switch for compressed obj pointers that
should make them go back to use 32bit pointers if possible, but
I fear those are available only in JDK 6 as an advanced option,
and JDK 7 by default (or something like that)
Interesting, good pice of info to know. Don't know if that is the case here but I have more than doubled the memory for maven and the jvm running the tests and it still seems to oom...
On 10-07-21 8:04 AM, Andrea Aime wrote:
Justin Deoliveira wrote:
Unfortunately it did not go so well. I could not get one build out due
to memory errors. Which seem to happen only in the app-schema module.
Ben any ideas there? Have you ever seen this. I have replicated memory
settings from the other hudson so it should be the same.
Anyways, I will continue on debugging these issues and will have to plan
the migration for something later this week hopefully.
Interesting. Are we switching from a 32bit host to a 64bit one?
It may be relevant as object pointers in 64bit use twice as much
space, so if we have a slew of small objects the increase can
be significant.
Modern JVM should have a switch for compressed obj pointers that
should make them go back to use 32bit pointers if possible, but
I fear those are available only in JDK 6 as an advanced option,
and JDK 7 by default (or something like that)
Cheers
Andrea
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Actually I take it back, setting the -XX:+UseCompressedOops parameter does indeed fix the problem. Nice one Andrea!!
On 10-07-21 8:04 AM, Andrea Aime wrote:
Justin Deoliveira wrote:
Unfortunately it did not go so well. I could not get one build out due
to memory errors. Which seem to happen only in the app-schema module.
Ben any ideas there? Have you ever seen this. I have replicated memory
settings from the other hudson so it should be the same.
Anyways, I will continue on debugging these issues and will have to plan
the migration for something later this week hopefully.
Interesting. Are we switching from a 32bit host to a 64bit one?
It may be relevant as object pointers in 64bit use twice as much
space, so if we have a slew of small objects the increase can
be significant.
Modern JVM should have a switch for compressed obj pointers that
should make them go back to use 32bit pointers if possible, but
I fear those are available only in JDK 6 as an advanced option,
and JDK 7 by default (or something like that)
Cheers
Andrea
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Good solution, Justin. I'm going to start using UseCompressedOops myself!
Does your use of this option indicate that Hudson is running Java 6 64-bit? Does this mean that 64-bit builds now work? Do we have CI coverage on Java 5 32-bit?
We might now have a new platform to test as UseCompressedOops objects could have different hashCode and thus HashMap behaviour. My old bugbear.
app-schema is known to build with -Dtest.maxHeapSize=256m on 32-bit (thanks to Gabriel's l33t skills!) but definitely needs more on 64-bit. EMF is quite bloated to start with, and app-schema does not share all the schemas it could.
Kind regards,
Ben.
On 22/07/10 01:56, Justin Deoliveira wrote:
Actually I take it back, setting the -XX:+UseCompressedOops parameter
does indeed fix the problem. Nice one Andrea!!
On 10-07-21 8:04 AM, Andrea Aime wrote:
Justin Deoliveira wrote:
Unfortunately it did not go so well. I could not get one build out due
to memory errors. Which seem to happen only in the app-schema module.
Ben any ideas there? Have you ever seen this. I have replicated memory
settings from the other hudson so it should be the same.
Anyways, I will continue on debugging these issues and will have to plan
the migration for something later this week hopefully.
Interesting. Are we switching from a 32bit host to a 64bit one?
It may be relevant as object pointers in 64bit use twice as much
space, so if we have a slew of small objects the increase can
be significant.
Modern JVM should have a switch for compressed obj pointers that
should make them go back to use 32bit pointers if possible, but
I fear those are available only in JDK 6 as an advanced option,
and JDK 7 by default (or something like that)
Cheers
Andrea
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
app-schema is known to build with -Dtest.maxHeapSize=256m on 32-bit (thanks to Gabriel's l33t skills!) but definitely needs more on 64-bit. EMF is quite bloated to start with, and app-schema does not share all the schemas it could.
Actually I believe more recent versions of EMF/XSD should be a bit more compact than the one we use.
If we manage to get CITE tests running against trunk
as well it may be a good time to try out an upgrade (on trunk only).
app-schema is known to build with -Dtest.maxHeapSize=256m on 32-bit (thanks to Gabriel's l33t skills!) but definitely needs more on 64-bit. EMF is quite bloated to start with, and app-schema does not share all the schemas it could.
Actually I believe more recent versions of EMF/XSD should be a bit more compact than the one we use.
If we manage to get CITE tests running against trunk
as well it may be a good time to try out an upgrade (on trunk only).
Reading the bug and the blogs confirms that the EMF memory usage was
nothing short of ridiculous, the latest and greatest is still high,
but much less so.
Good solution, Justin. I'm going to start using UseCompressedOops myself!
Does your use of this option indicate that Hudson is running Java 6
64-bit? Does this mean that 64-bit builds now work? Do we have CI
coverage on Java 5 32-bit?
As I am finding out no. 2.6.x built with a 64 bit jvm but trunk failed (coverage stuff). At this point I am probably going to try and just drop back to a 32 bit jvm.
We might now have a new platform to test as UseCompressedOops objects
could have different hashCode and thus HashMap behaviour. My old
bugbear.
app-schema is known to build with -Dtest.maxHeapSize=256m on 32-bit
(thanks to Gabriel's l33t skills!) but definitely needs more on 64-bit.
EMF is quite bloated to start with, and app-schema does not share all
the schemas it could.
Kind regards,
Ben.
On 22/07/10 01:56, Justin Deoliveira wrote:
Actually I take it back, setting the -XX:+UseCompressedOops parameter
does indeed fix the problem. Nice one Andrea!!
On 10-07-21 8:04 AM, Andrea Aime wrote:
Justin Deoliveira wrote:
Unfortunately it did not go so well. I could not get one build out due
to memory errors. Which seem to happen only in the app-schema module.
Ben any ideas there? Have you ever seen this. I have replicated memory
settings from the other hudson so it should be the same.
Anyways, I will continue on debugging these issues and will have to
plan
the migration for something later this week hopefully.
Interesting. Are we switching from a 32bit host to a 64bit one?
It may be relevant as object pointers in 64bit use twice as much
space, so if we have a slew of small objects the increase can
be significant.
Modern JVM should have a switch for compressed obj pointers that
should make them go back to use 32bit pointers if possible, but
I fear those are available only in JDK 6 as an advanced option,
and JDK 7 by default (or something like that)
app-schema is known to build with -Dtest.maxHeapSize=256m on 32-bit
(thanks to Gabriel's l33t skills!) but definitely needs more on 64-bit.
EMF is quite bloated to start with, and app-schema does not share all
the schemas it could.
Actually I believe more recent versions of EMF/XSD should be a bit more
compact than the one we use.
If we manage to get CITE tests running against trunk
as well it may be a good time to try out an upgrade (on trunk only).
Reading the bug and the blogs confirms that the EMF memory usage was
nothing short of ridiculous, the latest and greatest is still high,
but much less so.
This is good to know. I recently tried to upgrade to emf/xsd 2.5.0 to see if it would introduce any compelition errors and I am happy to say it didn't past a very few trivial ones.
Time to start testing (unit tests + cite) and seriously consider the upgrade.
Cheers
Andrea
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
