[Geoserver-users] GeoServer master (2.9.x) now requires Java 8

GeoTools master (2.9.x) now requires Java 8. The last 2.9.x release to support Java 7 is 2.9-M0.

GeoServer users wishing to use the latest master nightlies or future 2.9.x releases must upgrade to Java 8. Oracle JDK 8 is recommended. OpenJDK 8 is also supported.

GeoServer 2.8.x (current stable) and 2.7.x (current maintenance) releases will continue to support Java 7.

Note that in March 2016 stable will be 2.9.x and require Java 8. The maintenance branch will then be 2.8.x and will be supported on Java 7 until September 2016. After September 2016, no GeoServer versions will be supported on Java 7, so start planning your upgrades now.

Kind regards,

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

Thanks for this info, Ben

With the upgrade to Java 8 required for future versions of Geoserver and Geotools from September 2016 what are the implications for running Geoserver on 32-bit or 64-bit architectures?

The reason I ask is that I run 32-bit java and 32-bit Tomcat containers to use the Native JAI and ImageIO libraries with a 32-bit Java server Hotspot VM on Windows Server 2012.

If I upgrade to Java 8 and the server JRE then it is only available in 64-bit which means I need to upgrade my Tomcat and not use the native JAI libraries (there are no 64-bit Windows versions). Now, I might be getting mixed up here but does the new marlin renderer do the same thing as the native JAI libraries? Could I use that instead and still get the same performance?

I guess I could put in a business case to switch our servers to Linux based VMs...

Thanks

Ross

Ross McDonald | GIS Data Coordinator | Resources Department, IT Division | Angus Council, Angus House, Orchardbank Business Park, Forfar, DD8 1AT
T: 01307 476419 | F: 01307 476401 | E: mcdonaldr@anonymised.com

-----Original Message-----
From: Ben Caradoc-Davies [mailto:ben@anonymised.com]
Sent: 23 December 2015 00:21
To: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] GeoServer master (2.9.x) now requires Java 8

GeoTools master (2.9.x) now requires Java 8. The last 2.9.x release to support Java 7 is 2.9-M0.

GeoServer users wishing to use the latest master nightlies or future 2.9.x releases must upgrade to Java 8. Oracle JDK 8 is recommended.
OpenJDK 8 is also supported.

GeoServer 2.8.x (current stable) and 2.7.x (current maintenance) releases will continue to support Java 7.

Note that in March 2016 stable will be 2.9.x and require Java 8. The maintenance branch will then be 2.8.x and will be supported on Java 7 until September 2016. After September 2016, no GeoServer versions will be supported on Java 7, so start planning your upgrades now.

Kind regards,

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt; New Zealand

------------------------------------------------------------------------------
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

This message is strictly confidential. If you have received this in error, please inform the sender and remove it from your system. If received in error you may not copy, print, forward or use it or any attachment in any way. This message is not capable of creating a legal contract or a binding representation and does not represent the views of Angus Council. Emails may be monitored for security and network management reasons. Messages containing inappropriate content may be intercepted. Angus Council does not accept any liability for any harm that may be caused to the recipient system or data on it by this message or any attachment.

On Wed, Dec 23, 2015 at 5:45 PM, McDonaldR <McDonaldR@anonymised.com> wrote:

Thanks for this info, Ben

With the upgrade to Java 8 required for future versions of Geoserver and
Geotools from September 2016 what are the implications for running
Geoserver on 32-bit or 64-bit architectures?

The reason I ask is that I run 32-bit java and 32-bit Tomcat containers to
use the Native JAI and ImageIO libraries with a 32-bit Java server Hotspot
VM on Windows Server 2012.

We are abandoning native JAI and when JAI-EXT is ready to be enabled by
default, I believe we'll eventually stop recommending usage of native JAI
and probably remove it from the docs.
The reason is simple, we have no control over the native JAI and have been
piling up workarounds for it, while JAI-EXT we can optimize at will. I
don't have performance test yet (trying to make it correct before fast),
but weather.com is using it in their computational chain and are apparently
quite happy with the performance.

If I upgrade to Java 8 and the server JRE then it is only available in
64-bit which means I need to upgrade my Tomcat and not use the native JAI
libraries (there are no 64-bit Windows versions). Now, I might be getting
mixed up here but does the new marlin renderer do the same thing as the
native JAI libraries?

No, it's completely different. Marlin renderer speeds up the rendering of
vector data, not of raster data.
The benefit is more visible to those running a Oracle JDK (the only choice
on Windows) because the rasterizer Marlin replaces (Ductus) simply does not
scale up. Those running OpenJDK (on Linux) still get a nice boost, but
under load they are already getting good scalability.

Could I use that instead and still get the same performance?

I guess I could put in a business case to switch our servers to Linux
based VMs...

That's going to be beneficial regardless, anedoctal evidence is that Java
in general performs better on Linux (when I switched from Windows to Linux
as a developer enviroment the geotools and geoserver build times went down
a good 30%).
Over time others have found similar results:
http://itknowledgeexchange.techtarget.com/enterprise-linux/java-virtual-machine-performance-ubuntu-wins-over-windows/
http://www.theinquirer.net/inquirer/news/1050112/linux-runs-java-faster-windows

Now.. all these observations are a few years old and Windows might have
closed the gap
in the meantime, never had an occasion to test it in recent times honestly.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

*Geosolutions' Winter Holidays from 24/12 to 6/1*

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

Thanks Andrea

That’s useful to know.

I have set up a new Geoserver cluster as a test with Java 8.66 64bit, Tomcat 8.0.30 64bit and Geoserver 2.8 SNAPSHOT without the Native JAI libraries installed and using the JAI EXT jars (1.0.8) and the Marlin renderer and it seems to be OK.

The only niggle is the JMS clustering plugin (which works replicating changes across the instances) filling the log file with warning messages every few seconds:

30 Dec 14:56:01 WARN [network.DiscoveryNetworkConnector] - Could not start network bridge between: vm://426942e0-768c-459e-b85c-e2caa36e5063?async=false&network=true and: nio://127.0.0.1:59458 due to: java.net.ConnectException: Connection refused: no further information

30 Dec 14:56:03 WARN [network.DiscoveryNetworkConnector] - Could not start network bridge between: vm://426942e0-768c-459e-b85c-e2caa36e5063?async=false&network=true and: nio://127.0.0.1:59462 due to: java.net.ConnectException: Connection refused: no further information

30 Dec 14:56:08 WARN [network.DiscoveryNetworkConnector] - Could not start network bridge between: vm://426942e0-768c-459e-b85c-e2caa36e5063?async=false&network=true and: nio://127.0.0.1:59458 due to: java.net.ConnectException: Connection refused: no further information

I’ll put that into another email though.

Cheers

Ross

···

On Wed, Dec 23, 2015 at 5:45 PM, McDonaldR <McDonaldR@…6302…> wrote:

Thanks for this info, Ben

With the upgrade to Java 8 required for future versions of Geoserver and Geotools from September 2016 what are the implications for running Geoserver on 32-bit or 64-bit architectures?

The reason I ask is that I run 32-bit java and 32-bit Tomcat containers to use the Native JAI and ImageIO libraries with a 32-bit Java server Hotspot VM on Windows Server 2012.

We are abandoning native JAI and when JAI-EXT is ready to be enabled by default, I believe we’ll eventually stop recommending usage of native JAI and probably remove it from the docs.

The reason is simple, we have no control over the native JAI and have been piling up workarounds for it, while JAI-EXT we can optimize at will. I don’t have performance test yet (trying to make it correct before fast), but weather.com is using it in their computational chain and are apparently quite happy with the performance.

If I upgrade to Java 8 and the server JRE then it is only available in 64-bit which means I need to upgrade my Tomcat and not use the native JAI libraries (there are no 64-bit Windows versions). Now, I might be getting mixed up here but does the new marlin renderer do the same thing as the native JAI libraries?

No, it’s completely different. Marlin renderer speeds up the rendering of vector data, not of raster data.

The benefit is more visible to those running a Oracle JDK (the only choice on Windows) because the rasterizer Marlin replaces (Ductus) simply does not scale up. Those running OpenJDK (on Linux) still get a nice boost, but under load they are already getting good scalability.

Could I use that instead and still get the same performance?

I guess I could put in a business case to switch our servers to Linux based VMs…

That’s going to be beneficial regardless, anedoctal evidence is that Java in general performs better on Linux (when I switched from Windows to Linux as a developer enviroment the geotools and geoserver build times went down a good 30%).

Over time others have found similar results:

http://itknowledgeexchange.techtarget.com/enterprise-linux/java-virtual-machine-performance-ubuntu-wins-over-windows/

http://www.theinquirer.net/inquirer/news/1050112/linux-runs-java-faster-windows

Now… all these observations are a few years old and Windows might have closed the gap

in the meantime, never had an occasion to test it in recent times honestly.

Cheers

Andrea

==

GeoServer Professional Services from the experts! Visit

http://goo.gl/it488V for more information.

==

Geosolutions’ Winter Holidays from 24/12 to 6/1

Ing. Andrea Aime

@geowolf

Technical Lead

GeoSolutions S.A.S.

Via Poggio alle Viti 1187

55054 Massarosa (LU)

Italy

phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.