Thanks to Craig Jones for fixing the WPS resource leaks indicated by closing
the InputStream after use,
https://github.com/geoserver/geoserver/pull/1337/files
Could I get some comments on,
https://github.com/geoserver/geoserver/pull/1188.<https://github.com/geoserver/geoserver/pull/1188>
The current timeout behavior includes the time that the job has sat idle in the
queue. This means that a long-running wps job can cause subsequent jobs to be
evicted from the queue before they get a chance to start.
The PR enables a wps administrator to further set a job timeout that only
checks for the time that the job has actually been running.
Our use case is to avoid end-users from submitting long-running WPS jobs that
will cause other users' jobs to fail.
Cheers,
________________________________
From: Julian Atkinson <[email protected]>
Sent: Wednesday, September 30, 2015 7:13 AM
To: Jody Garnett; Andrea Aime
Cc: [email protected]
Subject: Re: [Geoserver-devel] Need advice on managing resources for WPS in
Geoserver
> This change makes the WPS non compliant, as there is no way to advertise a
> process cannot be called in a synch way, and in particular,
it makes the WPS fully non compliant (no process can be called anymore by a
standard client).
Thanks for the comments. This is reasonable and I voiced the same arguments
here myself. I'll close the PR.
________________________________
From: Jody Garnett <[email protected]>
Sent: Sunday, September 27, 2015 3:13 AM
To: Andrea Aime
Cc: Julian Atkinson; [email protected]
Subject: Re: [Geoserver-devel] Need advice on managing resources for WPS in
Geoserver
Been following this thread but not in position to comment, recommend discussion
on [email protected]<mailto:[email protected]>.
Ideally we could introduce something similar to ProcessDescription
statusSupported (which indicates if async is supported), so a "statusRequired"
could indicate if async is mandatory.
Short term I see/understand the need - and think it is best met with a prompt
service exception.
How to advertise the limitation in the GetCapabilities document is another
story - here are some ideas:
a) use a keyword (i.e. informal convention processes marked with a
"statusRequired" keyword can only be used async)
b) use a metadata URI (i.e. could make it a formal convention)
c) If you look at WPS 2.0 you may be able to define a role for processes that
can only be used async.
--
Jody Garnett
On 26 September 2015 at 02:18, Andrea Aime
<[email protected]<mailto:[email protected]>> wrote:
On Thu, Sep 24, 2015 at 12:22 AM, Julian Atkinson
<[email protected]<mailto:[email protected]>> wrote:
Hi All,
Andrea advised that I should discuss code features/workarounds that we
developed to address issues in the mailing list.
https://github.com/geoserver/geoserver/pull/1189
This PR provides an option to disable synchronous WPS requests via the GUI
admin panel.
I have seen the need to selectively disallow sync requests for specific
processes, this one goes further and disallows synch requests completely.
On a general WPS server this does not make sense, as there are many service
WPSs which are fast and small (e.g., JTS based ones),
but I guess you're restricting your consideration to one that serves one single
process, your custom one.
This change makes the WPS non compliant, as there is no way to advertise a
process cannot be called in a synch way, and in particular,
it makes the WPS fully non compliant (no process can be called anymore by a
standard client).
While I agree on the need for specific processes that are geared towards large
computations and known to take a lot of time, I'm skeptical
on a flag that disables asynch requests at the global level.
I also recognize nobody forces the admins to check that flag, but personally I
would be much more comfortable with a per process flag instead.
Can other core developers share an opinion on this topic?
For our plugin - a template driven netcdf encoder with cql support - we would
ideally have preferred synchronous+streaming behavior since that would
replicate our already successfully developed http service while adding the wps
protocol-support deemed necessary to satisfy an end-user contract.
However, we determined that fixing the resource leaks involving geotools
transactions and gt store jdbc connections was too high-risk for us to tackle.
As it stands, we rely on the above code to disable asynchronous support in
production, to avoid an http client
accidently initiating async actions that create geoserver instability.
If there are leaks you should report them. Unless it's your process that's
causing the leaks to start with of course.
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 Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313<tel:%2B39%200584%20962313>
fax: +39 0584 1660272<tel:%2B39%200584%201660272>
mob: +39 339 8844549<tel:%2B39%20%C2%A0339%208844549>
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-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
University of Tasmania Electronic Communications Policy (December, 2014).
This email is confidential, and is for the intended recipient only. Access,
disclosure, copying, distribution, or reliance on any of it by anyone outside
the intended recipient organisation is prohibited and may be a criminal
offence. Please delete if obtained in error and email confirmation to the
sender. The views expressed in this email are not necessarily the views of the
University of Tasmania, unless clearly intended otherwise.
------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
