On Sat, Oct 29, 2011 at 4:09 PM, Jody Garnett <[email protected]> wrote:
> Looked at that, seems quite a bit more than what I need, and harder to use
> from the point of view of polling.
> I'll stick to something more similar to what Gabriel did.
>
> Not sure I understand that one; you can poll for the current progress? The
> progress listener is used between the executing code (if it has actually
> started) and the value stored in the Progress for other code to check on.
>
> See above; I was expecting the ProcessExecutor to track this information;
> and the Progress data structure be the core of this response document.
> Process wise, we already have the factories pass down a ProgressListener
> among the call arguments, so the process can update its status.
>
> Yep, that's what I want to use. But Progress is no good, does not allow
> for cancellation, does not have the notion of "paused" state
> and forces the usage of Future, when doing restartable processes
> against persistent storage and checkpoints people should be free to
> use whatever they want imho.
>
> Good point out "paused"; it does actually allow cancelation last I checked.
Ah I see what you mean, Future has cancellation support, though I don't want
to support the boolean argument its provided with.
Still it has at the same time too much and not enough.
The interface forces the following:
V get(long timeout, TimeUnit unit)
which one might get for free if the thread control is managed inside the VM,
but only gets in the way otherwise (e.g., it's one more thing to implement
that provides no value WPS wise).
I want to be able to support a situation in which the WPS server is
just a frontend
for processes that do run off VM, maybe in a grid, where the progress manager
would actually offload the whole process and not run anything locally,
with the ability to reattach to the process running remotely even in case
of WPS server restart.
I don't want to tie myself to an API that assumes the process is running
locally using java.util.concurrent: although that will be the default
implementation,
I want to be free to support other variations.
> In any case I have not started using ProcessExecutor & Progress yet myself
> so if a solution is going to be in flux for a while I will hold off taking
> gt-process
> to supported status.
>
> A progress listener is all we need.
>
> Not strictly true as we need something to hold the result (or reference to
> the result).
I should have said "a progress listener is all we need status wise"
> The design is the same; ProcessManager extends ProcessExecutor; Status
> extends Progress.
>
> As said above, the interfaces over there do not seem suitable for what I
> need,
> I need interfaces that talk about what can be done in a WPS server allow
> for polling state and cancellation.
>
> Those two are covered; it is the pausing that is not covered.
How do I know if a process is queued or running?
Assuming getProgress()=0% implies queued is really lame, what if the process
is very long and the % does not go up for 10 minutes straight, or because of
its structure the process just reports status in very discrete steps?
Besides, as said, an interface that returns me with the map of outputs
won't take into account the need to generate the results on disk before
returning (see my first mail about streaming processes).
What I need here is some WPS server specific way to handle this,
otherwise streaming processes will just return at once without having
compute a thing and will start loading the server only as the external
output form (gml, shapefile, tiff) is being written.
These processes do run in the same vm as the WPS, but also pretty much
defeat the progress control, as said, they return instantly, the real
work is done later.
> Afaik the GeoTools ones are probably suitable for a desktop tool instead,
> but
> in practice nothing is using them?
>
> correct; I have not used them in a desktop tool yet either.
>
> If so maybe we can do like with the processes, port back reusable portions
> to GeoTools once the dust is settled.
> In any case I'll keep them on the desk along with Gabriel work and see what
> I can learn from them while building asynch support for GeoServer
>
> No worries; what is your timeframe Andrea? I kind of want this stuff settled
> before
> I sink more work into it.
I need to be able to start working on this Monday and close up later in the week
or at most beginning of the next.
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ now supports Android™ Apps
for the BlackBerry® PlayBook™. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
