[GRASS-user] The tomcat shut down when encounter some error grass commond

[maven apache]

---------- Forwarded message ----------
From: maven apache <apachemaven0 at gmail.com>
Date: 2009/9/20
Subject: Re: [GRASS-user] The tomcat shut down when encounter some error
grass commond
To: Glynn Clements <glynn at gclements.plus.com>



Thanks for your reply!
I am not exactly sure your meaning.
What is short-lived process and what is persisitent process>?
Did you mean that if a process takes long time,then a error can terminate
this thread? and the web server is in the same thread,so it is shut down?
If so ,does it mean that I should open a new thread for each grass commond?


2009/9/20 Glynn Clements <glynn at gclements.plus.com>


> maven apache wrote:
>
> > In my application ,I provide a interface which can called by users to
> > execute some geo process through the web,for example,user send a map,and
> a
> > width to the server ,then the server can do a buffer operation using the
> > grass(the server make the grass commond) according to the parameter from
> > client  .
> > But I found that if user give a invalide parameter, then the grass
> commond
> > maybe error, I can get the error message in the log, but my web server
> > (tomcat)shut down itself.
> > Any one have encountered the same suitation?
>
> The GRASS libraries typically handle errors by terminating the calling
> process via exit(). This eliminates the need for the caller to handle
> errors; either the function succeeds or the process is terminated.
>
> This approach is perfectly adequate for the intended use of the GRASS
> libraries, i.e. short-lived, non-interactive commands.
>
> OTOH, it's quite unsuitable for persistent processes, as any error
> will terminate the process. But persistent processes aren't the
> intended use of the GRASS libraries, and that isn't going to change.
>
> The problems with persistent processes aren't limited to error
> handling either. Many static variables are initialised upon first use
> and cannot be changed thereafter.
>
> If you want to use GRASS from within a web application, either run
> GRASS commands or fork() a new child process for each request.
>
> Finally, although you can override the fatal error handler with
> G_set_error_routine(), the supplied handler mustn't return, and you
> cannot safely use any GRASS functions once a fatal error has been
> detected, as the data structures used by the libraries will be in an
> undefined state.
>
>

> --
> Glynn Clements <glynn at gclements.plus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20090920/be7d012e/attachment.html