The tomcat shut down when encounter some error grass commond

[kkk]

Hi,

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?

 

Annex is my java class to set up the grass environment. I  hope some can check it and identify it if any problem exist.

The GrassMain is the main class to set up the environment,the GrassThread is to get the output result , the GrassThreadError is to get the error message if so.

Thanks!

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Glynn Clements]

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 <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[kkk]

---------- Forwarded message ----------
From: maven apache <[hidden email]>
Date: 2009/9/20
Subject: Re: [GRASS-user] The tomcat shut down when encounter some error grass commond
To: Glynn Clements <[hidden email]>

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 <[hidden email]>

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 <[hidden email]>

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Glynn Clements]

maven apache wrote:

> I am not exactly sure your meaning.
> What is short-lived process and what is persisitent process>?

By "short-lived non-interactive command", I'm talking about a typical
GRASS command: it reads parameters from the command line, performs
some processing, then exits. If there are any errors, then it just
exits, often without performing any significant processing.

By "persistent process" I'm talking about something like a daemon or a
GUI application, which performs multiple operations, and keeps
performing operations until it is specifically instructed to
terminate.

> Did you mean that if a process takes long time,then a error can terminate
> this thread?

It doesn't matter how long it takes; any error will normally terminate
the process. For a simple command, this isn't a problem; if the
library function didn't terminate the process, the main program would
terminate itself once the error was reported.

But for a persistent process which performs multiple operations, an
error would normally result in it aborting the current operation then
proceding to the next operation. This isn't possible if you're using
the GRASS libraries, as they don't generally permit the process to
continue after an error has occurred.

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

This is about processes, not threads.

AFAIK, Tomcat behaves as a server, receiving requests from Apache and
passing them to Java modules for processing. If you use Tomcat to run
a module which uses GRASS library functions, if the GRASS library
function signals an error, it will call exit() which will terminate
the current process, i.e. it will terminate Tomcat.

If you want to avoid this, you need to process each request in a
separate *process*; a separate thread doesn't help, as exit()
terminates the process, not just a thread.

AFAICT, Java doesn't have an equivalent of fork() (which doesn't exist
on Windows); the normal mechanism for creating processes is with
Runtime.exec(). I have no idea whether this is even permitted from
within Tomcat, or whether there are any complications involved.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[kkk]

Thanks Glynn Clements:

I noticed that you have mentioned Grass library more than one times?

I think I did not use them?

I just have three java class the handle the grass commond,and the real call of grass is through the Runtime.exec() method ,it do open a new process.

2009/9/21 Glynn Clements <[hidden email]>

maven apache wrote:

> I am not exactly sure your meaning.
> What is short-lived process and what is persisitent process>?

By "short-lived non-interactive command", I'm talking about a typical
GRASS command: it reads parameters from the command line, performs
some processing, then exits. If there are any errors, then it just
exits, often without performing any significant processing.

By "persistent process" I'm talking about something like a daemon or a
GUI application, which performs multiple operations, and keeps
performing operations until it is specifically instructed to
terminate.

> Did you mean that if a process takes long time,then a error can terminate
> this thread?

It doesn't matter how long it takes; any error will normally terminate
the process. For a simple command, this isn't a problem; if the
library function didn't terminate the process, the main program would
terminate itself once the error was reported.

But for a persistent process which performs multiple operations, an
error would normally result in it aborting the current operation then
proceding to the next operation. This isn't possible if you're using
the GRASS libraries, as they don't generally permit the process to
continue after an error has occurred.

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

This is about processes, not threads.

AFAIK, Tomcat behaves as a server, receiving requests from Apache and
passing them to Java modules for processing. If you use Tomcat to run
a module which uses GRASS library functions, if the GRASS library
function signals an error, it will call exit() which will terminate
the current process, i.e. it will terminate Tomcat.

If you want to avoid this, you need to process each request in a
separate *process*; a separate thread doesn't help, as exit()
terminates the process, not just a thread.

AFAICT, Java doesn't have an equivalent of fork() (which doesn't exist
on Windows); the normal mechanism for creating processes is with
Runtime.exec(). I have no idea whether this is even permitted from
within Tomcat, or whether there are any complications involved.

--

Glynn Clements <[hidden email]>

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Glynn Clements]

maven apache wrote:

> Thanks Glynn Clements:
> I noticed that you have mentioned Grass library more than one times?
> I think I did not use them?
> I just have three java class the handle the grass commond,and the real call
> of grass is through the Runtime.exec() method ,it do open a new process.

In which case, I have no idea why Tomcat is terminating.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[achim]

After installing the new SVN of GRASS 6.5, I get following error using
v.category:

ERROR: Incompatible library version for module. You need to rebuild GRASS
       or untangle multiple installations.

Can anybody help please?

Has it to do with the grass-addons I installed before?

Achim

PS: OpenSuse11.1 64bit
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Nikos Alexandris]

On Mon, 2009-09-21 at 14:56 +0200, achim wrote:
> Incompatible library version for module

Hi Achim :-)

Recompile the gdal-grass-plugin. That should be it [1][2].

Gruesse, Nikos
---

[1]
http://n2.nabble.com/error-Incompatible-library-version-for-module-You-need-to-rebuild-GRASS-or-untangle-multiple-install-td3347116.html#a3347116
[2]
http://lists.osgeo.org/pipermail/grass-stats/2009-January/000897.html


_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[achim]

:-)

Hi Nikos,

that did it!

(reinstalled gdal-grass, make clean, make, make install)

Thanks a lot,
Achim


Nikos Alexandris schrieb:

> On Mon, 2009-09-21 at 14:56 +0200, achim wrote:
>> Incompatible library version for module
>
> Hi Achim :-)
>
> Recompile the gdal-grass-plugin. That should be it [1][2].
>
> Gruesse, Nikos
> ---
>
> [1]
> http://n2.nabble.com/error-Incompatible-library-version-for-module-You-need-to-rebuild-GRASS-or-untangle-multiple-install-td3347116.html#a3347116
> [2]
> http://lists.osgeo.org/pipermail/grass-stats/2009-January/000897.html
>
>

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Nikos Alexandris]

On Mon, 2009-09-21 at 15:31 +0200, achim wrote:

> :-)
>
> Hi Nikos,
>
> that did it!
>
> (reinstalled gdal-grass, make clean, make, make install)
>
> Thanks a lot,
> Achim

Thanks to the "others". I am repeating this mistake myself many times.

Nikos

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

["Sören Gebbert"]

Hello maven,
i guess the problem  is located in your GrassMain.java line 200:

                                if (ps.exitValue() != 0) {
                                        System.exit(ps.exitValue());
                                }

AFAIK, the tomcat server uses a container to run the several servlet threads
inside.
If you call from any servlet thread the System.exit() command, the server will
be shutdown.

Java doc of System.exit():
Terminates the currently running Java Virtual Machine.

Best regards
Soeren

Am Sunday 20 September 2009 05:21:29 schrieb maven apache:

> Hi,
> 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?
>
> Annex is my java class to set up the grass environment. I  hope some can
> check it and identify it if any problem exist.
> The GrassMain is the main class to set up the environment,the GrassThread
> is to get the output result , the GrassThreadError is to get the error
> message if so.
> Thanks!

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

["Sören Gebbert"]

Hi,

Am Sunday 20 September 2009 14:18:58 schrieb Glynn Clements:

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

Well, thats exactly the problem that i face with grass trying to run several
operations within on process using the vtkGRASSBridge.
Is there any chance to implement a conterpart to G_init() like G_uninit()
to compute several tasks in one process (not multithreaded).

Is there really no way to reset the static variables to initial state?

Best regards
Soeren

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Glynn Clements]

Sören Gebbert wrote:

> > 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.
>
> Well, thats exactly the problem that i face with grass trying to run several
> operations within on process using the vtkGRASSBridge.
> Is there any chance to implement a conterpart to G_init() like G_uninit()
> to compute several tasks in one process (not multithreaded).
>
> Is there really no way to reset the static variables to initial state?

The variables are littered throughout the various source files of the
various libraries, and initialisation upon first use is a common idiom
in GRASS.

You would need to identify all of the relevant variables, make them
non-"static", and add a function to reset them. You would need a
separate reset function for each library. And you would need to keep
track of any new variables which were added (don't rely upon
developers co-operating; I've had trouble implementing "no static
data" policies even on projects which were generally well-organised).

Oh; and some of the libraries which GRASS uses may have their own
static data, so you would have to figure out how to reset those
libraries.

For lib/gis and and lib/raster, searching for "struct state" (in 7.0)
will find many of them. Beyond that, searching the output from "nm"
for symbols of type B, D, b and d will show static variables (some of
which never change, but aren't in the rodata segment because adding
the "const" qualifier introduces compatibility issues).

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[kkk]

2009/9/23 Sören Gebbert <[hidden email]>

Hello maven,
i guess the problem  is located in your GrassMain.java line 200:

                               if (ps.exitValue() != 0) {
                                       System.exit(ps.exitValue());
                               }

AFAIK, the tomcat server uses a container to run the several servlet threads
inside.
If you call from any servlet thread the System.exit() command, the server will
be shutdown.

Java doc of System.exit():

Hi,thanks, you are right, I have solved this problem,but I want to know how to judge a grass commond(called in my javaProgram) is successfully exected?

Terminates the currently running Java Virtual Machine.

Best regards
Soeren

Am Sunday 20 September 2009 05:21:29 schrieb maven apache:

> Hi,
> 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?
>
> Annex is my java class to set up the grass environment. I  hope some can
> check it and identify it if any problem exist.
> The GrassMain is the main class to set up the environment,the GrassThread
> is to get the output result , the GrassThreadError is to get the error
> message if so.
> Thanks!

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[kkk]

2009/9/23 Sören Gebbert <[hidden email]>

Hello maven,
i guess the problem  is located in your GrassMain.java line 200:

                               if (ps.exitValue() != 0) {
                                       System.exit(ps.exitValue());
                               }

AFAIK, the tomcat server uses a container to run the several servlet threads
inside.
If you call from any servlet thread the System.exit() command, the server will
be shutdown.

Java doc of System.exit():
Terminates the currently running Java Virtual Machine.

Thanks, you are right! ^_^

I have solved this problem,however I want to know how to judge whether the grass commond(which I call in my program)is executed successfully?

Best regards
Soeren

Am Sunday 20 September 2009 05:21:29 schrieb maven apache:

> Hi,
> 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?
>
> Annex is my java class to set up the grass environment. I  hope some can
> check it and identify it if any problem exist.
> The GrassMain is the main class to set up the environment,the GrassThread
> is to get the output result , the GrassThreadError is to get the error
> message if so.
> Thanks!

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

> Hi,thanks, you are right, I have solved this
> problem,but I want to know how to judge a grass
> commond(called in my javaProgram) is successfully
> exected?


check this:
> >   if (ps.exitValue() != 0) {

??

exit values:

0 == success
1 == failure
other = failure


Hamish




_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Francesco Mirabella]

Hi all,
I am trying to compile some grass-addons. I tried both "g.extension" and
compiling from the svn repository. For example, for r.stream.extract,
when running make I get:

------------------------------------------------------------------------------------------------------------------------------------
francesco@terra17:/usr/local/cvs/grass/grass-addons/raster/r.stream.extract$
make
MODULE_TOPDIR=/usr/local/cvs/grass/grass-7.0.svn_src_snapshot_2009_09_12/
test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu
gcc
-I/usr/local/cvs/grass/grass-7.0.svn_src_snapshot_2009_09_12/dist.i686-pc-linux-gnu/include
-I/usr/local/cvs/grass/grass-7.0.svn_src_snapshot_2009_09_12/dist.i686-pc-linux-gnu/include
  -g -O2    -I/usr/include/gdal   -DPACKAGE=\""grassmods"\"
-I/usr/local/cvs/grass/grass-7.0.svn_src_snapshot_2009_09_12/dist.i686-pc-linux-gnu/include
-I/usr/local/cvs/grass/grass-7.0.svn_src_snapshot_2009_09_12/dist.i686-pc-linux-gnu/include
-o OBJ.i686-pc-linux-gnu/close.o -c close.c
close.c:4:24: error: grass/Vect.h: No such file or directory
In file included from close.c:5:
local_proto.h:46: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '*' token
local_proto.h:47: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '*' token
local_proto.h:48: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '*' token
local_proto.h:63: error: expected declaration specifiers or '...' before
'CELL'
close.c: In function 'close_streamvect':
close.c:21: error: storage size of 'Out' isn't known
close.c:41: warning: assignment makes pointer from integer without a cast
close.c:42: warning: assignment makes pointer from integer without a cast
close.c:57: error: 'stream' undeclared (first use in this function)
close.c:57: error: (Each undeclared identifier is reported only once
close.c:57: error: for each function it appears in.)
close.c:67: error: 'GV_POINT' undeclared (first use in this function)
close.c:144: error: 'GV_LINE' undeclared (first use in this function)
close.c:162: error: 'GV_1TABLE' undeclared (first use in this function)
close.c:162: warning: assignment makes pointer from integer without a cast
close.c:163: error: dereferencing pointer to incomplete type
close.c:163: error: dereferencing pointer to incomplete type
close.c:165: error: dereferencing pointer to incomplete type
close.c:168: error: dereferencing pointer to incomplete type
close.c:169: error: dereferencing pointer to incomplete type
close.c:170: error: dereferencing pointer to incomplete type
close.c:174: error: dereferencing pointer to incomplete type
close.c:183: error: dereferencing pointer to incomplete type
close.c:186: error: dereferencing pointer to incomplete type
close.c:188: error: dereferencing pointer to incomplete type
close.c:196: error: dereferencing pointer to incomplete type
close.c:215: error: dereferencing pointer to incomplete type
close.c:216: error: dereferencing pointer to incomplete type
close.c:216: error: dereferencing pointer to incomplete type
close.c: In function 'close_maps':
close.c:233: error: 'CELL' undeclared (first use in this function)
close.c:233: error: 'cell_buf1' undeclared (first use in this function)
close.c:233: error: 'cell_buf2' undeclared (first use in this function)
close.c:235: error: storage size of 'history' isn't known
close.c:246: error: 'CELL_TYPE' undeclared (first use in this function)
close.c:263: error: 'stream' undeclared (first use in this function)
make: *** [OBJ.i686-pc-linux-gnu/close.o] Error 1
------------------------------------------------------------------------------------------------------------------------------------

Similar problems for other modules, e.g. v.profile

Can someone give hints??

best  wishes
Francesco



--
**********************************************
Francesco Mirabella,
Geologia Strutturale e Geofisica
Universita' di Perugia,
Dipartimento di Scienze della Terra,
Piazza Universita' 1, 06100 Perugia (Italy)
**********************************************

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Martin Landa]

Hi,

[...]

simply the most of modules from GRASS Add-ons need to updated for GRASS7.

* use raster library, include grass/raster.h
* grass/Vect.h -> grass/vector.h

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user