[Geoserver-devel] Need advice on managing resources for WPS in Geoserver

Julian_Atkinson · June 2, 2015, 8:37am

Hi All,

We are attempting to integrate a WPS service into Geoserver 2.7.0 and have some issues around resource management.

Briefly, our WPS Process involves,

Implementing a GeoServerProcess that uses the execute() method to return a class deriving from RawData.
Implementing the RawData.getInputStream() method to return an InputStream object. This object holds refs to a Geotools transaction object and a jdbc connection taken from a Geotools jdbcdatastore. These resources are used to consume and transform data - which is returned via calls on the InputStream’s read() methods.

We found that,

During synchronous WPS calls, if the remote client prematurely terminates the connection, there is no corresponding call back on the InputStream’s close() method. Without this notification we are unable to properly cleanup the geotools transaction and jdbc connection resources.
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.

With the above issues in mind, we modified our approach to use a FileOutputStream created via resourceManager.getOutputResource(). The prevents the WPS job from being prematurely marked as complete until all data is written to the file. However it’s not our preferred choice for web-browsers since there’s no indication of any connection/download activity.

We also used the ProgressListener to monitor job state, by testing the progressListener.isCanceled() while processing. However we noticed,

That if the remote client disconnects we still don’t get notification of completion via the ProgressListener.

A couple of other minor issues,

timeouts begin from the time the job is queued, not the time the job run is started.
It’s not possible to set the max synchronous jobs to zero via the GUI as an indirect way to disable synchronous WPS jobs

Any advice would be greatly appreciated,

Cheers,
Julian

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.

Andrea_Aime4 · June 2, 2015, 10:15am

On Tue, Jun 2, 2015 at 10:37 AM, Julian Atkinson <j.f.c.atkinson@anonymised.com

wrote:

Hi All,

We are attempting to integrate a WPS service into Geoserver 2.7.0 and have
some issues around resource management.

Briefly, our WPS Process involves,
- Implementing a GeoServerProcess that uses the execute() method to
return a class deriving from RawData.
- Implementing the RawData.getInputStream() method to return an
InputStream object. This object holds refs to a Geotools transaction object
and a jdbc connection taken from a Geotools jdbcdatastore. These resources
are used to consume and transform data - which is returned via calls on the
InputStream's read() methods.

We found that,

- During synchronous WPS calls, if the remote client prematurely
terminates the connection, there is no corresponding call back on the
InputStream's close() method. Without this notification we are unable to
properly cleanup the geotools transaction and jdbc connection resources.

Sounds like a bug. Please open a ticket, and if you can, follow with a pull
request to solve the issue.

- 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.

With the above issues in mind, we modified our approach to use a
FileOutputStream created via resourceManager.getOutputResource(). The
prevents the WPS job from being prematurely marked as complete until all
data is written to the file. However it's not our preferred choice for
web-browsers since there's no indication of any connection/download
activity.

Marked as complete... where? In the WPS protocol, or in the status store?

We also used the ProgressListener to monitor job state, by testing the
progressListener.isCanceled() while processing. However we noticed,

- That if the remote client disconnects we still don't get notification of
completion via the ProgressListener.

Same as above, ticket and pull request welcomed. Mind though, a client
disconnection cannot be determined as it happens,
the servlets only tell us about the disconnection via an exception thrown
as we try to write the output on the response output stream.

A couple of other minor issues,
- timeouts begin from the time the job is queued, not the time the job
run is started.

Yes, I can see that... does not seem like it's easy to change that though,
we have nothing marking the
actual execution beginning... well, unless we wrapped the process with
something that notifies the MaxExecutionTimeListener
and then cascades the execute call. It's probably the less painful way.
Maybe this wrapper could also be a way to push the encoding in the
execution thread pool.

- It's not possible to set the max synchronous jobs to zero via the GUI
as an indirect way to disable synchronous WPS jobs

This is indeed not possible, and not formally correct either: as far as I
know, there is no way to communicate the client that a process
cannot be executed in synchronous mode, so denying it would probably be a
protocol violation.
I can see how it's desirable though, some processes are just running for
too much time to be usable in synch mode, but having a simple
blanket statement that no process should be run in synch mode is too
restrictive.
I'd try to add a per process setting instead.

Any advice would be greatly appreciated,

Cheers,
Julian

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.

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

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

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.

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

Julian_Atkinson · June 3, 2015, 8:00am

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.

···

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?

Cheers
Julian

Julian_Atkinson · June 3, 2015, 8:07am

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?

Cheers
Julian

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.

Andrea_Aime4 · June 3, 2015, 8:13am

On Wed, Jun 3, 2015 at 10:07 AM, Julian Atkinson <j.f.c.atkinson@anonymised.com

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.

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

Julian_Atkinson · September 23, 2015, 10:22pm

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

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.

···

From: andrea.aime@anonymised.com… andrea.aime@anonymised.com on behalf of Andrea Aime <andrea.aime@anonymised.com…1268…>
Sent: Wednesday, June 3, 2015 6:13 PM
To: Julian Atkinson
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] Need advice on managing resources for WPS in Geoserver

On Wed, Jun 3, 2015 at 10:07 AM, Julian Atkinson <j.f.c.atkinson@anonymised.com> 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.

Julian_Atkinson · September 23, 2015, 10:36pm

to disable asynchronous support in production, to avoid an http client
accidently initiating async actions that create geoserver instability.

asynchronous should read synchronous. Sorry for the confusion.

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.

···

From: Julian Atkinson
Sent: Thursday, September 24, 2015 8:22 AM
To: Andrea Aime
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] Need advice on managing resources for WPS in Geoserver

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: andrea.aime@anonymised.com… andrea.aime@anonymised.com on behalf of Andrea Aime <andrea.aime@anonymised.com…1268…>
Sent: Wednesday, June 3, 2015 6:13 PM
To: Julian Atkinson
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] Need advice on managing resources for WPS in Geoserver

On Wed, Jun 3, 2015 at 10:07 AM, Julian Atkinson <j.f.c.atkinson@anonymised.com> 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.

Andrea_Aime4 · September 26, 2015, 9:18am

On Thu, Sep 24, 2015 at 12:22 AM, Julian Atkinson <
j.f.c.atkinson@anonymised.com> 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.

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

jive · September 26, 2015, 5:13pm

Been following this thread but not in position to comment, recommend discussion on standards@…1503….

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.

···

On 26 September 2015 at 02:18, Andrea Aime <andrea.aime@anonymised.com> wrote:

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Jody Garnett

On Thu, Sep 24, 2015 at 12:22 AM, Julian Atkinson <j.f.c.atkinson@anonymised.com> 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.

Julian_Atkinson · September 29, 2015, 9:13pm

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.

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.

···

From: Jody Garnett jody.garnett@anonymised.com
Sent: Sunday, September 27, 2015 3:13 AM
To: Andrea Aime
Cc: Julian Atkinson; geoserver-devel@lists.sourceforge.net
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 standards@anonymised.com.

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 <andrea.aime@anonymised.com> wrote:

On Thu, Sep 24, 2015 at 12:22 AM, Julian Atkinson <j.f.c.atkinson@anonymised.com> 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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Julian_Atkinson · November 26, 2015, 8:55pm

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.

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 j.f.c.atkinson@anonymised.com
Sent: Wednesday, September 30, 2015 7:13 AM
To: Jody Garnett; Andrea Aime
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] Need advice on managing resources for WPS in Geoserver