Re: [Geoserver-users] GetFeatureInfo with info_format=application/vnd.ogc.gml/3.1.1 causes memory leak

2016-12-07 Thread Jan De Moerloose 

  
  
Andrea,

I prepared a pull request with your suggested fix that seems to fix
the problem (not ready for merging!):
https://github.com/geoserver/geoserver/pull/2005

Please have a look and let me know how to proceed further,

Cheers,
Jan

On 12/05/2016 10:14 AM, Jan De
  Moerloose wrote:


  
  Created the issue: https://osgeo-org.atlassian.net/browse/GEOS-7887
  
  I will try to follow up your suggestion today and report here.
  
  Cheers,
  Jan
  On 12/03/2016 11:17 AM, Andrea Aime
wrote:
  
  

  
On Fri, Dec 2, 2016 at 11:06 AM,
  Jan De Moerloose 
  wrote:
  
 Hi,
  
  i think i may have found a memory leak in the WMS
  service of geoserver. It occurs when executing
  multiple (identical) GetFeatureInfo requests on one of
  the demo layers.
  The way to reproduce it is as follows:
  
  - deploy the latest stable geoserver war (2.10.0) on
  tomcat
  - execute the following curl command
  
  curl "127.0.0.1:8080/geoserver/ows?SERVICE=WMS=1.1.1&REQUEST=GetFeatureInfo=image%2Fpng=true&QUERY_LAYERS=tiger%3Apoly_landmarks=tiger%3Apoly_landmarks_FORMAT=application%2Fvnd.ogc.gml%2F3.1.1_COUNT=50=50=50=EPSG%3A4326=101&HEIGHT=101=-73.97317886352539%2C40.81266403198242%2C-73.93850326538086%2C40.84733963012695
  =[1-3000]" > out.txt
  
  With 1G of memory, the server comes to a halt after
  about 1000 requests.
  A heap dump shows that memory is occupied by eclipse
  schema classes (emf).
  
  A search on the issue tracker did not reveal anything.
  Any ideas or could anyone try to reproduce ?

  
  
  
  Our GML encoder is unfortunately schema driven,
meaning we need to build a in memory xml schema for it
to work.
  
  

I'm not 100% sure, but I'm afraid the developer
  originally building the GML output format for feature into
  created the leak by 
building over and over a WFS schema in memory, that
  unfortunately causes the leak
(due to how XSD and EMF work, each WFS schema instance
  gets referred back from the GML schemas, which are
  singletons).


If my hypothesis is correct, the code should be amended
  to refer to the wfsXsd-1.1 and xmlConfiguration-1.1 stored
  in the
spring context instead or re-creating them over and
  over, acting in fashion similar to the WFS
  GML3OutputFormat class.


WMS does already depend on the WFS module in that very
  class by imports, so adding a wiring at the spring level
  is not
going to cause more issues.


Is that something you can try to build? 
In any case, I'd start by opening a ticket with steps
  to reproduce at https://osgeo-org.atlassian.net/projects/GEOS/summary


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

Re: [Geoserver-users] GetFeatureInfo with info_format=application/vnd.ogc.gml/3.1.1 causes memory leak

2016-12-05 Thread Jan De Moerloose 

  
  
Created the issue: https://osgeo-org.atlassian.net/browse/GEOS-7887

I will try to follow up your suggestion today and report here.

Cheers,
Jan
On 12/03/2016 11:17 AM, Andrea Aime
  wrote:


  

  On Fri, Dec 2, 2016 at 11:06 AM, Jan
De Moerloose 
wrote:

   Hi,

i think i may have found a memory leak in the WMS
service of geoserver. It occurs when executing multiple
(identical) GetFeatureInfo requests on one of the demo
layers.
The way to reproduce it is as follows:

- deploy the latest stable geoserver war (2.10.0) on
tomcat
- execute the following curl command

curl
"127.0.0.1:8080/geoserver/ows?SERVICE=WMS=1.1.1&REQUEST=GetFeatureInfo=image%2Fpng=true&QUERY_LAYERS=tiger%3Apoly_landmarks=tiger%3Apoly_landmarks_FORMAT=application%2Fvnd.ogc.gml%2F3.1.1_COUNT=50=50=50=EPSG%3A4326=101&HEIGHT=101=-73.97317886352539%2C40.81266403198242%2C-73.93850326538086%2C40.84733963012695
=[1-3000]" > out.txt

With 1G of memory, the server comes to a halt after
about 1000 requests.
A heap dump shows that memory is occupied by eclipse
schema classes (emf).

A search on the issue tracker did not reveal anything.
Any ideas or could anyone try to reproduce ?
  



Our GML encoder is unfortunately schema driven, meaning
  we need to build a in memory xml schema for it to work.


  
  I'm not 100% sure, but I'm afraid the developer
originally building the GML output format for feature into
created the leak by 
  building over and over a WFS schema in memory, that
unfortunately causes the leak
  (due to how XSD and EMF work, each WFS schema instance
gets referred back from the GML schemas, which are
singletons).
  
  
  If my hypothesis is correct, the code should be amended
to refer to the wfsXsd-1.1 and xmlConfiguration-1.1 stored
in the
  spring context instead or re-creating them over and over,
acting in fashion similar to the WFS GML3OutputFormat class.
  
  
  WMS does already depend on the WFS module in that very
class by imports, so adding a wiring at the spring level is
not
  going to cause more issues.
  
  
  Is that something you can try to build? 
  In any case, I'd start by opening a ticket with steps to
reproduce at https://osgeo-org.atlassian.net/projects/GEOS/summary
  
  
  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.

Re: [Geoserver-users] GetFeatureInfo with info_format=application/vnd.ogc.gml/3.1.1 causes memory leak

2016-12-03 Thread Andrea Aime 
On Fri, Dec 2, 2016 at 11:06 AM, Jan De Moerloose <
jan.demoerlo...@geosparc.com> wrote:

> Hi,
>
> i think i may have found a memory leak in the WMS service of geoserver. It
> occurs when executing multiple (identical) GetFeatureInfo requests on one
> of the demo layers.
> The way to reproduce it is as follows:
>
> - deploy the latest stable geoserver war (2.10.0) on tomcat
> - execute the following curl command
>
> curl "127.0.0.1:8080/geoserver/ows?SERVICE=WMS=1.1.1&
> REQUEST=GetFeatureInfo=image%2Fpng=true&
> QUERY_LAYERS=tiger%3Apoly_landmarks=tiger%
> 3Apoly_landmarks_FORMAT=application%2Fvnd.ogc.gml%2F3.
> 1.1_COUNT=50=50=50=EPSG%3A4326=101&
> HEIGHT=101=-73.97317886352539%2C40.81266403198242%2C-73.
> 93850326538086%2C40.84733963012695
> =[1-3000]" > out.txt
>
> With 1G of memory, the server comes to a halt after about 1000 requests.
> A heap dump shows that memory is occupied by eclipse schema classes (emf).
>
> A search on the issue tracker did not reveal anything. Any ideas or could
> anyone try to reproduce ?
>

Our GML encoder is unfortunately schema driven, meaning we need to build a
in memory xml schema for it to work.

I'm not 100% sure, but I'm afraid the developer originally building the GML
output format for feature into created the leak by
building over and over a WFS schema in memory, that unfortunately causes
the leak
(due to how XSD and EMF work, each WFS schema instance gets referred back
from the GML schemas, which are singletons).

If my hypothesis is correct, the code should be amended to refer to
the wfsXsd-1.1 and xmlConfiguration-1.1 stored in the
spring context instead or re-creating them over and over, acting in fashion
similar to the WFS GML3OutputFormat class.

WMS does already depend on the WFS module in that very class by imports, so
adding a wiring at the spring level is not
going to cause more issues.

Is that something you can try to build?
In any case, I'd start by opening a ticket with steps to reproduce at
https://osgeo-org.atlassian.net/projects/GEOS/summary

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.

---
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] GetFeatureInfo with info_format=application/vnd.ogc.gml/3.1.1 causes memory leak

2016-12-02 Thread Jan De Moerloose 

  
  
Hi,

i think i may have found a memory leak in the WMS service of
geoserver. It occurs when executing multiple (identical)
GetFeatureInfo requests on one of the demo layers.
The way to reproduce it is as follows:

- deploy the latest stable geoserver war (2.10.0) on tomcat
- execute the following curl command


curl
"127.0.0.1:8080/geoserver/ows?SERVICE=WMS=1.1.1=GetFeatureInfo=image%2Fpng=true_LAYERS=tiger%3Apoly_landmarks=tiger%3Apoly_landmarks_FORMAT=application%2Fvnd.ogc.gml%2F3.1.1_COUNT=50=50=50=EPSG%3A4326=101=101=-73.97317886352539%2C40.81266403198242%2C-73.93850326538086%2C40.84733963012695
=[1-3000]" > out.txt

With 1G of memory, the server comes to a halt after about 1000
requests.
A heap dump shows that memory is occupied by eclipse schema classes
(emf).

A search on the issue tracker did not reveal anything. Any ideas or
could anyone try to reproduce ?

Kind Regards,

Jan De Moerloose
Geosparc





  


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users