Been following this thread but not in position to comment, recommend discussion on [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]> wrote: > On Thu, Sep 24, 2015 at 12:22 AM, Julian Atkinson < > [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 > 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-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > >
------------------------------------------------------------------------------
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
