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.
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.
https://github.com/geoserver/geoserver/pull/1188
Changes the wps execution limit to apply only to job execution time. Existing
behavior that includes both queue and execution time is maintained using the
totalTime attributes.
Regards
Julian
________________________________
From: [email protected] <[email protected]> on behalf of Andrea Aime
<[email protected]>
Sent: Wednesday, June 3, 2015 6:13 PM
To: Julian Atkinson
Cc: [email protected]
Subject: Re: [Geoserver-devel] Need advice on managing resources for WPS in
Geoserver
On Wed, Jun 3, 2015 at 10:07 AM, Julian Atkinson
<[email protected]<mailto:[email protected]>> wrote:
Thanks for your help Andrea,
>> - As soon as the InputStream is returned to the WPS executor, the job is
>> marked as complete, even though it may take many hours to process and stream
>> all the data. Additionally, any new WPS jobs are run immediately without
>> respecting queue limits.
> The queue is just for the "execute" phase. If you can change the code so that
> it also does also the encoding in the execute thread, that would be
> appreciated.
We re-arranged our code to block in the execute phase with our second
implementation (generating the complete response and writing it to file
storage, before returning from execute).
The apparent limitation is that the execute() method is also responsible for
returning the RawData interface that supplies the InputStream which the wps
extension code uses to return the response back to the client.
This prevents any streaming of buffered content while it is being generated in
a synchronous context - even if we use separate producer and consumer threads.
Instead the wps execution IO workflow seems to be organized around discreet
jobs. Is that an accurate description of the behavior?
If it is, I don't understand it :-)
As far as I know streaming is possible, but it will happen in a thread other
than the ones in the pool, thus dodging the concurrent execution limits
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
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.
-------------------------------------------------------
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.
------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
