[Geoserver-users] Memory Leak seemingly caused by Monitoring plugin

GeoServer GeoServer User
1

Setup is: RHEL 6, GeoServer (war) 2.10.0, Jetty 9.3, PostgreSQL 9.4, monitoring plugin with hibernate enabled, configured for JNDI datasource provided by Jetty c3p0

System is under pretty heavy use (1000’s of requests per hour) and while the extension does what its intended to do, we end up with an unstable GeoServer after several hours and must be restarted. System reports resident memory slowly increasing unbounded for the java process. At about 2x the max heap size setting it starts to fall over. Services become unreachable and log starts printing huge lists of threads. Even the shutdown signal to Jetty seems to be ignored and the process must be SIGKILL’d.

monitor.properties:

storage=hibernate

mode=history

sync=async

maxBodySize=0

db.properties:

defaultAutoCommit=false

hibernate.properties:

databasePlatform=org.hibernate.dialect.PostgreSQLDialect
database=POSTGRESQL
hibernate.use_sql_comments=true
generateDdl=true
hibernate.format_sql=true
showSql=false
hibernate.generate_statistics=true
hibernate.session_factory_name=SessionFactory
hibernate.hbm2ddl.auto=update
hibernate.bytecode.use_reflection_optimizer=true
hibernate.show_sql=false

I’m curious if this has been reported before if anyone can provide leads as to the cause. I checked JIRA and didn’t see anything. I’m willing to peak around in the monitor code.

Also, a lot of our users and using KML superoverlays and this causes about 90% of our requests to be operation=‘dispatch’ which seem completely useless to me. Anyone know what the purpose of that is? I’m interested in making a configuration parameter to ignore these.

···

Jason Newmoyer
Newmoyer Geospatial Solutions
843.606.0424
jason@anonymised.com

2

On Fri, Dec 2, 2016 at 7:11 PM, Jason Newmoyer <jason@anonymised.com

wrote:

Setup is: RHEL 6, GeoServer (war) 2.10.0, Jetty 9.3, PostgreSQL 9.4,
monitoring plugin with hibernate enabled, configured for JNDI datasource
provided by Jetty c3p0

I know that saving with hibernate tends to become slower and slower and ...
slower, but that is related to the inserts themselves
on the table, checking for the primary key uniqueness becomes progressively
slower until it becomes completely
unusable. That's why, at least in my company, we never use the hibernate
storage, but enable audit mode to dump
on file instead, and then transfer the info into elasticsearch using
logstash.

Database storage progressive slowdown should be fixable by removing the
primary key, however that is probably going to require
other changes, I have vague memories that the code might saving a record
and then updating it later, which might not work
without a primary key to refer to for the update statement.

System is under pretty heavy use (1000's of requests per hour) and while
the extension does what its intended to do, we end up with an unstable
GeoServer after several hours and must be restarted. System reports
resident memory slowly increasing unbounded for the java process. At about
2x the max heap size setting it starts to fall over. Services become
unreachable and log starts printing huge lists of threads. Even the
shutdown signal to Jetty seems to be ignored and the process must be
SIGKILL'd.

You should collect a memory dump using jmap when things start getting bad
and see what's filling the memory.
Or just get one using Yourkit, they do have a 15 days trials license which
is normally good enough for a one-off analysis.

I'm curious if this has been reported before if anyone can provide leads
as to the cause. I checked JIRA and didn't see anything. I'm willing to
peak around in the monitor code.

Also, a lot of our users and using KML superoverlays and this causes about
90% of our requests to be operation='dispatch' which seem completely
useless to me. Anyone know what the purpose of that is? I'm interested in
making a configuration parameter to ignore these.

I'm not sure about this one... You probably want to check somewhere around
here:
https://github.com/geoserver/geoserver/blob/master/src/extension/monitor/core/src/main/java/org/geoserver/monitor/ows/MonitorCallback.java#L77
although you'll probably also end up looking into the main dispatcher here:
https://github.com/geoserver/geoserver/blob/master/src/ows/src/main/java/org/geoserver/ows/Dispatcher.java

I'm making a guess here, maybe you are hitting some GWC service? Those are
not playing by the same rules as the GeoServer inner ones
and I believe that could be a reason why monitoring has troubles figuring
out the details

Cheers
Andrea

--

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

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
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.

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

3

Thank you for the thorough response. I will poke around with JMap and see what I can figure out.

The GWC service is indeed the primary endpoint being requested.

I’m also suspect of our memory settings in PostgreSQL. We have tons of memory available and use pgtune to make use of it.

I’ll let you know what I find out.

···

On Sat, Dec 3, 2016 at 4:42 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Jason Newmoyer
Newmoyer Geospatial Solutions
843.606.0424
jason@anonymised.com

On Fri, Dec 2, 2016 at 7:11 PM, Jason Newmoyer <jason@anonymised.com> wrote:

Setup is: RHEL 6, GeoServer (war) 2.10.0, Jetty 9.3, PostgreSQL 9.4, monitoring plugin with hibernate enabled, configured for JNDI datasource provided by Jetty c3p0

I know that saving with hibernate tends to become slower and slower and … slower, but that is related to the inserts themselves
on the table, checking for the primary key uniqueness becomes progressively slower until it becomes completely
unusable. That’s why, at least in my company, we never use the hibernate storage, but enable audit mode to dump
on file instead, and then transfer the info into elasticsearch using logstash.

Database storage progressive slowdown should be fixable by removing the primary key, however that is probably going to require
other changes, I have vague memories that the code might saving a record and then updating it later, which might not work
without a primary key to refer to for the update statement.

System is under pretty heavy use (1000’s of requests per hour) and while the extension does what its intended to do, we end up with an unstable GeoServer after several hours and must be restarted. System reports resident memory slowly increasing unbounded for the java process. At about 2x the max heap size setting it starts to fall over. Services become unreachable and log starts printing huge lists of threads. Even the shutdown signal to Jetty seems to be ignored and the process must be SIGKILL’d.

You should collect a memory dump using jmap when things start getting bad and see what’s filling the memory.
Or just get one using Yourkit, they do have a 15 days trials license which is normally good enough for a one-off analysis.

I’m curious if this has been reported before if anyone can provide leads as to the cause. I checked JIRA and didn’t see anything. I’m willing to peak around in the monitor code.

Also, a lot of our users and using KML superoverlays and this causes about 90% of our requests to be operation=‘dispatch’ which seem completely useless to me. Anyone know what the purpose of that is? I’m interested in making a configuration parameter to ignore these.

I’m not sure about this one… You probably want to check somewhere around here:
https://github.com/geoserver/geoserver/blob/master/src/extension/monitor/core/src/main/java/org/geoserver/monitor/ows/MonitorCallback.java#L77

although you’ll probably also end up looking into the main dispatcher here:
https://github.com/geoserver/geoserver/blob/master/src/ows/src/main/java/org/geoserver/ows/Dispatcher.java

I’m making a guess here, maybe you are hitting some GWC service? Those are not playing by the same rules as the GeoServer inner ones
and I believe that could be a reason why monitoring has troubles figuring out the details

Cheers
Andrea

–

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

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
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.

4

Hi Jason,
did you find out what was going on in the end?

Cheers
Andrea

···

On Wed, Dec 7, 2016 at 9:01 PM, Jason Newmoyer <jason@anonymised.com> wrote:

Thank you for the thorough response. I will poke around with JMap and see what I can figure out.

The GWC service is indeed the primary endpoint being requested.

I’m also suspect of our memory settings in PostgreSQL. We have tons of memory available and use pgtune to make use of it.

I’ll let you know what I find out.

–

Jason Newmoyer
Newmoyer Geospatial Solutions
843.606.0424
jason@anonymised.com

On Sat, Dec 3, 2016 at 4:42 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Dec 2, 2016 at 7:11 PM, Jason Newmoyer <jason@anonymised.com> wrote:

Setup is: RHEL 6, GeoServer (war) 2.10.0, Jetty 9.3, PostgreSQL 9.4, monitoring plugin with hibernate enabled, configured for JNDI datasource provided by Jetty c3p0

I know that saving with hibernate tends to become slower and slower and … slower, but that is related to the inserts themselves
on the table, checking for the primary key uniqueness becomes progressively slower until it becomes completely
unusable. That’s why, at least in my company, we never use the hibernate storage, but enable audit mode to dump
on file instead, and then transfer the info into elasticsearch using logstash.

Database storage progressive slowdown should be fixable by removing the primary key, however that is probably going to require
other changes, I have vague memories that the code might saving a record and then updating it later, which might not work
without a primary key to refer to for the update statement.

System is under pretty heavy use (1000’s of requests per hour) and while the extension does what its intended to do, we end up with an unstable GeoServer after several hours and must be restarted. System reports resident memory slowly increasing unbounded for the java process. At about 2x the max heap size setting it starts to fall over. Services become unreachable and log starts printing huge lists of threads. Even the shutdown signal to Jetty seems to be ignored and the process must be SIGKILL’d.

You should collect a memory dump using jmap when things start getting bad and see what’s filling the memory.
Or just get one using Yourkit, they do have a 15 days trials license which is normally good enough for a one-off analysis.

I’m curious if this has been reported before if anyone can provide leads as to the cause. I checked JIRA and didn’t see anything. I’m willing to peak around in the monitor code.

Also, a lot of our users and using KML superoverlays and this causes about 90% of our requests to be operation=‘dispatch’ which seem completely useless to me. Anyone know what the purpose of that is? I’m interested in making a configuration parameter to ignore these.

I’m not sure about this one… You probably want to check somewhere around here:
https://github.com/geoserver/geoserver/blob/master/src/extension/monitor/core/src/main/java/org/geoserver/monitor/ows/MonitorCallback.java#L77

although you’ll probably also end up looking into the main dispatcher here:
https://github.com/geoserver/geoserver/blob/master/src/ows/src/main/java/org/geoserver/ows/Dispatcher.java

I’m making a guess here, maybe you are hitting some GWC service? Those are not playing by the same rules as the GeoServer inner ones
and I believe that could be a reason why monitoring has troubles figuring out the details

Cheers
Andrea

–

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

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
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.

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

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
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.

5

I’ll paste an output from jmap -hist below, but I don’t see anything really obvious.

After taking a look at the hibernate connection code/config, I see that its creating its own org.apache.commons.dbcp.BasicDataSource. I’m thinking of adding a check for a new property “jndi” and if exists, then grab the connection from jndi and return it. This would be in https://github.com/geoserver/geoserver/blob/master/src/extension/monitor/hibernate/src/main/java/org/geoserver/monitor/hib/MonitoringDataSource.java#L43. I feel like this would be a productive change as it gives users more flexibility on the datastore. Not sure if it will help me debug the original issue or not.

Debugger attached successfully.
Server compiler detected.
JVM version is 25.91-b14
Iterating over heap. This may take a while…
Object Histogram:

num #instances #bytes Class description

···

On Sat, Dec 10, 2016 at 10:43 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi Jason,
did you find out what was going on in the end?

Cheers

Andrea

Jason Newmoyer
Newmoyer Geospatial Solutions
843.606.0424
jason@anonymised.com

On Wed, Dec 7, 2016 at 9:01 PM, Jason Newmoyer <jason@anonymised.com…> wrote:

Thank you for the thorough response. I will poke around with JMap and see what I can figure out.

The GWC service is indeed the primary endpoint being requested.

I’m also suspect of our memory settings in PostgreSQL. We have tons of memory available and use pgtune to make use of it.

I’ll let you know what I find out.

–

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

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
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.

Jason Newmoyer
Newmoyer Geospatial Solutions
843.606.0424
jason@anonymised.com

On Sat, Dec 3, 2016 at 4:42 AM, Andrea Aime <andrea.aime@anonymised.com107…> wrote:

On Fri, Dec 2, 2016 at 7:11 PM, Jason Newmoyer <jason@anonymised.com> wrote:

Setup is: RHEL 6, GeoServer (war) 2.10.0, Jetty 9.3, PostgreSQL 9.4, monitoring plugin with hibernate enabled, configured for JNDI datasource provided by Jetty c3p0

I know that saving with hibernate tends to become slower and slower and … slower, but that is related to the inserts themselves
on the table, checking for the primary key uniqueness becomes progressively slower until it becomes completely
unusable. That’s why, at least in my company, we never use the hibernate storage, but enable audit mode to dump
on file instead, and then transfer the info into elasticsearch using logstash.

Database storage progressive slowdown should be fixable by removing the primary key, however that is probably going to require
other changes, I have vague memories that the code might saving a record and then updating it later, which might not work
without a primary key to refer to for the update statement.

System is under pretty heavy use (1000’s of requests per hour) and while the extension does what its intended to do, we end up with an unstable GeoServer after several hours and must be restarted. System reports resident memory slowly increasing unbounded for the java process. At about 2x the max heap size setting it starts to fall over. Services become unreachable and log starts printing huge lists of threads. Even the shutdown signal to Jetty seems to be ignored and the process must be SIGKILL’d.

You should collect a memory dump using jmap when things start getting bad and see what’s filling the memory.
Or just get one using Yourkit, they do have a 15 days trials license which is normally good enough for a one-off analysis.

I’m curious if this has been reported before if anyone can provide leads as to the cause. I checked JIRA and didn’t see anything. I’m willing to peak around in the monitor code.

Also, a lot of our users and using KML superoverlays and this causes about 90% of our requests to be operation=‘dispatch’ which seem completely useless to me. Anyone know what the purpose of that is? I’m interested in making a configuration parameter to ignore these.

I’m not sure about this one… You probably want to check somewhere around here:
https://github.com/geoserver/geoserver/blob/master/src/extension/monitor/core/src/main/java/org/geoserver/monitor/ows/MonitorCallback.java#L77

although you’ll probably also end up looking into the main dispatcher here:
https://github.com/geoserver/geoserver/blob/master/src/ows/src/main/java/org/geoserver/ows/Dispatcher.java

I’m making a guess here, maybe you are hitting some GWC service? Those are not playing by the same rules as the GeoServer inner ones
and I believe that could be a reason why monitoring has troubles figuring out the details

Cheers
Andrea

–

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

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
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.