You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by hernan <hb...@gmail.com> on 2011/12/14 23:45:33 UTC
Running not multithreaded application
Hello,
I'm using Tomcat 7.0 for developing a new application. A key component in
the application have to run an external not multithreaded application.
Since I'm not an experienced user in Tomcat, I wonder which implementation
alternatives do you recommend for running my external application. I'm
trying to avoid launch a new os process from java since I need the result
of that process, so in this way I've to deal communicating two processes
(may be using serializable objects using sockets).
I want to know which kind of approachs are used to deal with these type of
situations.
Thanks in advance.
Regards,
Hernán
Re: Running not multithreaded application
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hernán,
On 12/23/11 4:24 PM, hernan wrote:
> Process p = Runtime.getRuntime().exec(...);
>
> // Sending input to process p OutputStream os =
> p.getOutputStream(); BufferedWriter bw = new BufferedWriter(new
> OutputStreamWriter(os)); [...] // send input through bw
> bw.close(); os.close();
>
> // Receiving output from process p InputStream is =
> p.getInputStream(); BufferedReader br = new BufferedReader(new
> InputStreamReader(is)); [...] // receiving output through br
> br.close(); is.close();
>
> I will add the stderr to this code.
If you just add similar stderr code after your stdout handling code,
you may still suffer a deadlock: if the stderr buffer fills up, the
child process will block waiting for you to read it, and output to
stdout will stall as well. I think the commons folks have a component
to handle all of this stuff for you in a tidy package.
> My next step is write a Scheduler class, may be a "singleton" or
> something similar to work as a resource-limiter, also I will need
> other rules related to users and sessions. Actually, when the
> threshold is reached, the Scheduler should queue the "job". For the
> moment I will think that the queue capacity is infinite :).
>
> I wonder which alternatives do I have to implement my Scheduler
> class in tomcat. In fact, I've to read a lot about tomcat, so I've
> started reading the apache tomcat 7 (Vukotic and Goodwill) to
> understand how tomcat works exactly.
I'm not sure that you need anything Tomcat-specific for this. Just
something that will work in any servlet container should be sufficient.
If you just want to limit resources and give anyone who exceeds the
limit a "sorry, try again" message, it shouldn't be too difficult to
implement with an atomic counter.
If you want to implement queuing, then you'll probably also want the
clients to continue to issue "update" requests to find out if their
job was completed. That will certainly be more complicated, but
probably more robust. You'll want to look at Java's "executors" for
that: you can queue a job and get a "Future" object that you can poll
for completeness. Stick that object in the session after queuing the
job and use something like META REFRESH or Ajax calls to periodically
check the status of the job. If the user logs out, you might want to
mark the job as cancelled just so you don't waste your time. I would
also *not* allow an infinite queue length.
There are of course lots of other ways to do this kind of thing.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk70+sYACgkQ9CaO5/Lv0PC5HgCfeTdI8bVDgMXuln0HW2tdnuxo
qFYAniTf6OSaeES8Fi69yJBfbcpRGJNW
=KSqB
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Running not multithreaded application
Posted by hernan <hb...@gmail.com>.
On Fri, Dec 23, 2011 at 12:00 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hernan,
>
> On 12/22/11 9:47 PM, hernan wrote:
> > Finally, I'm just using Runtime.exec() to execute a c++ program
> > that uses glpk, and using stdin/stdout to communicate them. The
> > whole system is running tomcat, axis2, java and c/c++.
>
> Just be very careful about thread and stream management when using
> Runtime.exec(): you must consume everything from both stdout *and*
> stderr, otherwise you can lock-up the thread and bring down your
> server. You might want to have a resource-limiter on the number of
> concurrent calls to GLPK processes just to make sure there are always
> some threads available for other things like monitoring (including
> reporting the number of GLPK processes that are running).
>
Yes, I agree. The I send all the input to the process and close the
channel, then the process read all the input and start the processing phase
when all the input is received. Actually it does not work like a
traditional pipe but this solution works for me.
Process p = Runtime.getRuntime().exec(...);
// Sending input to process p
OutputStream os = p.getOutputStream();
BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(os));
[...] // send input through bw
bw.close();
os.close();
// Receiving output from process p
InputStream is = p.getInputStream();
BufferedReader br = new BufferedReader(new InputStreamReader(is));
[...] // receiving output through br
br.close();
is.close();
I will add the stderr to this code.
My next step is write a Scheduler class, may be a "singleton" or something
similar to work as a resource-limiter, also I will need other rules related
to users and sessions. Actually, when the threshold is reached,
the Scheduler should queue the "job". For the moment I will think that the
queue capacity is infinite :).
I wonder which alternatives do I have to implement my Scheduler class in
tomcat. In fact, I've to read a lot about tomcat, so I've started reading
the apache tomcat 7 (Vukotic and Goodwill) to understand how tomcat works
exactly.
http://www.amazon.com/Apache-Tomcat-7-Aleksa-Vukotic/dp/1430237236/ref=sr_1_cc_1?s=gift-cards&ie=UTF8&qid=1324673900&sr=1-1-catcorr
If you have some other lecture for suggest me, it will be appreciated.
> > I don't know about the demand for linear-physics-via-HTTP, it's
> > only about a service for inventory and order management.
>
> I think I'm lost. What are you using GLPK for, then?
There are many logistics decisions that companies have to execute his
everyday operations about procurement, inventory, distribution and
sales. For example, if a company has a depot that receives a lot of orders
from point of sales, and they have to ship products from a depot to
customers using trucks, they have to choose which product (for a customer)
put in each truck and in which order each truck visits each customer. In
general there are capacity constraints (due to physical limitations of the
trucks -i.e. weight, size, ...) and organizations want to optimize some
metric(s) (for example, mean delivery time, fuel consumption, etc.).
There is a lot of literature about this kind of problems, if you're
interested may be you can start in:
http://en.wikipedia.org/wiki/Vehicle_routing_problem
Using glpk you can model this kind of problems and find solutions using the
glpk or rewrite some routines to write your own algorithm to find
solutions.
Regards,
Hernán
Re: Running not multithreaded application
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hernan,
On 12/22/11 9:47 PM, hernan wrote:
> Finally, I'm just using Runtime.exec() to execute a c++ program
> that uses glpk, and using stdin/stdout to communicate them. The
> whole system is running tomcat, axis2, java and c/c++.
Just be very careful about thread and stream management when using
Runtime.exec(): you must consume everything from both stdout *and*
stderr, otherwise you can lock-up the thread and bring down your
server. You might want to have a resource-limiter on the number of
concurrent calls to GLPK processes just to make sure there are always
some threads available for other things like monitoring (including
reporting the number of GLPK processes that are running).
> I don't know about the demand for linear-physics-via-HTTP, it's
> only about a service for inventory and order management.
I think I'm lost. What are you using GLPK for, then?
> Thanks a lot for your comments and suggestions!!!
Good luck!
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk70l3kACgkQ9CaO5/Lv0PAOZgCdGzZs+SjjrbwIv4rTobdtrNJ3
pkEAoKnsO5s/3CfHmmlKUrXlxcLJprDZ
=bD4w
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Running not multithreaded application
Posted by hernan <hb...@gmail.com>.
On Thu, Dec 15, 2011 at 4:48 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hernan,
>
> On 12/15/11 12:47 PM, hernan wrote:
> > As separate process, I thought a java "server" process with the
> > wrapper that receive requests, launch a new process an response
> > with the result. The servlet (thread) calls the process using some
> > kind of client/server mechanism implemented in java (may be
> > sockets).
>
> So in order to avoid calling Runtime.exec() from Tomcat, you're going
> to write another service that mimics quite a bit of what Tomcat does,
> and then call Runtime.exec() from that? Hrm.
>
> So, you'd have this:
>
> Client -> Tomcat -> GLPK Service -> Java Wrapper (GLPK)
>
> That seems entirely unnecessary.
>
> > I agree, just doing Runtime.exec(binary), the disadvantage with
> > Runtime is that I'll not use java classes to comunicate
> > input/output of the process.
>
> Aah... so GLPK generates output that is better consumed as serialized
> Java objects? What about on-disk artifacts or some kind of non-binary
> output? I'm just thinking out loud. I hate Java serialization in most
> cases.
>
> > I've run successfully using syncronized methods, but I have to
> > handle concurrent requests and I don't want to serialize them
> > because the response times may be very different between them and I
> > don't want some user have to wait a lot for a "simple" request.
>
> Yup. Makes sense. That pretty much rules-out in-process use of GLPK.
>
> Are there any plans from the GLPK folks to make their code threadsafe?
> That would certainly be nice...
>
> > This is the main concern for me. For that reason I prefeer run glpk
> > in a different os process. I see two big ways: serving each servlet
> > request with a different process or run a different process/es
> > dedicated only to glpk. The first way is what I have to learn, but
> > it seems that tomcat does not support. In the second, I have more
> > job coordinating processes and manipulating input/output.
>
> I would start-out just using Runtime.exec() and communicating via
> stdin/stdout with (I guess) serialized Java objects. That seems so
> disgusting to me, but it's slightly less odious than writing a TCP/IP
> service wrapper to essentially do the same thing.
>
> > In my experience GLPK is stable, and I've been doing some
> > (serialized) tests on java wrapper and they run successfully. But
> > I'm not 99% sure that will be perfect, and mainly I don't trust in
> > the program/programmer (me) that uses the library. I don't want
> > that tomcat crash due to some request.
>
> That's a good policy.
>
> > Connecting apache htttpd server with tomcat, can I run several
> > tomcat instances and run each http request in a different tomcat
> > instance?
>
> Uh, yes, but not the way you want to. It sounds like you want to run
> Tomcat like an inetd-style service, which is going to get you nowhere.
> It takes Tomcat so long to start up that you may as well just
> serialize access to your GLPK library. Actually, I'll bet Tomcat can't
> even be used as an inetd-style service.
>
> > I know that this is not the tomcat philosophy, but I just want to
> > know if it is possible or is common this approach for this kind of
> > situations.
>
> Er... you may be able to beat it into shape, but it will be horribly
> unstable and just a terrible all-around idea. Look elsewhere.
>
> > My principal requirements are: stability (main concern),
> > scalability, serving concurrent requests (no more than 100
> > concurrent requests). If possible: flexibility/maintainability.
> >
> > I think that your option #4 is the appropriate in this situation.
>
> Do you have any opportunities for batch-processing these requests?
> That way, an HTTP request essentially amounts to a queuing operation.
> You have a single-threaded, background process that does the "real"
> work (possibly by running multiple, parallel copies of GLPK) and
> deposits an artifact for each task somewhere (database, on-disk file,
> etc.). That might simplify the architecture. *shrug*
>
> This doesn't seem like a simple thing to do in general. Is there high
> demand for linear-physics-via-HTTP processing?
Finally, I'm just using Runtime.exec() to execute a c++ program that uses
glpk, and using stdin/stdout to communicate them. The whole system is
running tomcat, axis2, java and c/c++.
I don't know about the demand for linear-physics-via-HTTP, it's only about
a service for inventory and order management.
Thanks a lot for your comments and suggestions!!!
Regards,
Hernán
Re: Running not multithreaded application
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hernan,
On 12/15/11 12:47 PM, hernan wrote:
> As separate process, I thought a java "server" process with the
> wrapper that receive requests, launch a new process an response
> with the result. The servlet (thread) calls the process using some
> kind of client/server mechanism implemented in java (may be
> sockets).
So in order to avoid calling Runtime.exec() from Tomcat, you're going
to write another service that mimics quite a bit of what Tomcat does,
and then call Runtime.exec() from that? Hrm.
So, you'd have this:
Client -> Tomcat -> GLPK Service -> Java Wrapper (GLPK)
That seems entirely unnecessary.
> I agree, just doing Runtime.exec(binary), the disadvantage with
> Runtime is that I'll not use java classes to comunicate
> input/output of the process.
Aah... so GLPK generates output that is better consumed as serialized
Java objects? What about on-disk artifacts or some kind of non-binary
output? I'm just thinking out loud. I hate Java serialization in most
cases.
> I've run successfully using syncronized methods, but I have to
> handle concurrent requests and I don't want to serialize them
> because the response times may be very different between them and I
> don't want some user have to wait a lot for a "simple" request.
Yup. Makes sense. That pretty much rules-out in-process use of GLPK.
Are there any plans from the GLPK folks to make their code threadsafe?
That would certainly be nice...
> This is the main concern for me. For that reason I prefeer run glpk
> in a different os process. I see two big ways: serving each servlet
> request with a different process or run a different process/es
> dedicated only to glpk. The first way is what I have to learn, but
> it seems that tomcat does not support. In the second, I have more
> job coordinating processes and manipulating input/output.
I would start-out just using Runtime.exec() and communicating via
stdin/stdout with (I guess) serialized Java objects. That seems so
disgusting to me, but it's slightly less odious than writing a TCP/IP
service wrapper to essentially do the same thing.
> In my experience GLPK is stable, and I've been doing some
> (serialized) tests on java wrapper and they run successfully. But
> I'm not 99% sure that will be perfect, and mainly I don't trust in
> the program/programmer (me) that uses the library. I don't want
> that tomcat crash due to some request.
That's a good policy.
> Connecting apache htttpd server with tomcat, can I run several
> tomcat instances and run each http request in a different tomcat
> instance?
Uh, yes, but not the way you want to. It sounds like you want to run
Tomcat like an inetd-style service, which is going to get you nowhere.
It takes Tomcat so long to start up that you may as well just
serialize access to your GLPK library. Actually, I'll bet Tomcat can't
even be used as an inetd-style service.
> I know that this is not the tomcat philosophy, but I just want to
> know if it is possible or is common this approach for this kind of
> situations.
Er... you may be able to beat it into shape, but it will be horribly
unstable and just a terrible all-around idea. Look elsewhere.
> My principal requirements are: stability (main concern),
> scalability, serving concurrent requests (no more than 100
> concurrent requests). If possible: flexibility/maintainability.
>
> I think that your option #4 is the appropriate in this situation.
Do you have any opportunities for batch-processing these requests?
That way, an HTTP request essentially amounts to a queuing operation.
You have a single-threaded, background process that does the "real"
work (possibly by running multiple, parallel copies of GLPK) and
deposits an artifact for each task somewhere (database, on-disk file,
etc.). That might simplify the architecture. *shrug*
This doesn't seem like a simple thing to do in general. Is there high
demand for linear-physics-via-HTTP processing?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7qTykACgkQ9CaO5/Lv0PBr1wCfQvMwnBPYIrJ33QhuRRX6R4gm
FOcAnRLfchlvlMW+dY91k5qWsO+npukt
=fA6f
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Running not multithreaded application
Posted by hernan <hb...@gmail.com>.
On Thu, Dec 15, 2011 at 12:25 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hernan,
>
> On 12/14/11 7:15 PM, hernan wrote:
> > On Wed, Dec 14, 2011 at 8:17 PM, Christopher Schultz <
> >> What makes this "external" "program" non-multithreaded? Is it
> >> actually not threadsafe?
> >>
> >> If you can't run it in the same process as Tomcat, then you'll
> >> have to either use Runtime.exec or some type of wrapper around it
> >> -- or have that process running completely separately (as a
> >> daemon) and connect to it via sockets. Anything else requires
> >> native code, which you definitely don't want.
> >
> > My external application is a java application that uses java
> > wrapper (using JNI) for GLPK (written in ANSI C)
> > (http://www.gnu.org/s/glpk/), and GLPK is not threadsafe. Yes, I
> > will consider those alternatives, executing a new process when I
> > receive the request (Runtime.exec) and a separated deamon receiving
> > requests launching those processes.
>
> So, you're already running native code, eh? Well, you have several
> options IMO:
>
> 1. Run the thing as a separate process, wrapped in Java. This requires
> that you run Runtime.exec() and call the Java wrapper you have.
> I'm not entirely sure why you'd bother with the Java wrapper if you
> were going to call-out to a separate program, but it's an option.
> See #2 for caveats.
>
As separate process, I thought a java "server" process with the
wrapper that receive requests, launch a new process an response with the
result. The servlet (thread) calls the process using some kind of
client/server mechanism implemented in java (may be sockets).
> 2. Run the thing as a separate process *directly*. That is, instead of
> doing Runtime.exec("/path/to/java/wrapper"), you'd just do
> Runtime.exec("/path/to/native/binary"). You'll get better performance
> and will avoid the native code required to bridge from Java to
> native, which is likely to improve stability.
> On the other hand, Runtime.exec() is a monster, and you can deadlock
> your thread(s) easily if you don't know what you are doing.
> Runtime.exec() essentially requires 2 threads per call because you
> have to monitor both stdout and stderr and consume them otherwise
> you risk deadlock. You might want to use a wrapper library to improve
> your chances.
>
I agree, just doing Runtime.exec(binary), the disadvantage with Runtime is
that I'll not use java classes to comunicate input/output of the process.
> 3. Run the thing in-process with Tomcat, but use some kind of service
> that isolates and serializes access to the non-threadsafe library.
> You can do this with a singleton (or something like it) that has
> a synchronized "run-GLPK" method: that will restrict callers such
> that only one of them can use the library at a time.
> I highly recommend that you try to acquire a lock using a timeout
> instead of just blindly calling a synchronized method otherwise
> you might end up in a deadlock situation if the library (or your
> code) stalls at some point.
>
I've run successfully using syncronized methods, but I have to handle
concurrent requests and I don't want to serialize them because the response
times may be very different between them and I don't want some user have to
wait a lot for a "simple" request.
> Another caveat: running JNI within a server process has inherent
> risks of crashing the native module (if there is a bug in DLPK or
> in the native wrapper around it) which will bring-down your whole
> Tomcat service: that's obviously bad.
>
This is the main concern for me. For that reason I prefeer run glpk in a
different os process. I see two big ways: serving each servlet request with
a different process or run a different process/es dedicated only to
glpk. The first way is what I have to learn, but it seems that tomcat does
not support. In the second, I have more job coordinating processes and
manipulating input/output.
> 4. As I suggested before, run GLPK as a daemon process and communicate
> with it via sockets or whatever. Has anyone written a GLPK-service?
>
> So, perhaps the simplest thing to do is #3, but it has the most
> runtime risks. The safest thing is to run as a separate process and
> communicate via sockets, but that might require significant investment
> in infrastructure (to build the service, then call-out to it).
>
> Are there any other requirements? For example: do you need to be able
> to handle multiple simultaneous incoming HTTP requests that all need
> to use GLPK? Or, is this relatively rare? If you need high
> concurrency, then option #3 simply isn't going to work unless the
> operations are very fast (which I suspect they are not).
>
> Do you have any idea how stable GLPK is? How about the native wrapper
> in Java?
In my experience GLPK is stable, and I've been doing some (serialized)
tests on java wrapper and they run successfully. But I'm not 99% sure that
will be perfect, and mainly I don't trust in the
program/programmer (me) that uses the library. I don't want that tomcat
crash due to some request.
> > Can I configure tomcat for running a new (or different) process for
> > each request?
>
> No. Tomcat runs in a single JVM, pretty much by definition. You can
> get Tomcat to run a *servlet* as a new instance of the class that
> defines it (by using SingleThreadModel) but that does not help you,
> here, and is a deprecated capability anyway.
Ok
> > or I have to run Apache HTTP Server and connect it to Tomcat?
>
> That's not necessary, either, although it might make it easier to wrap
> a service around GLPK with a simple set of CGI-BIN-style scripts
> written in Bash, Perl, etc.
Ok
> > If I have to run Apache HTTP Server which mechanism do I have to
> > connect it with tomcat? using Jk connector is the standard way?
>
> If you have to add httpd to the mix, you basically have 3 choices:
>
> 1. mod_proxy_http (uses HTTP protocol, comes bundled with httpd)
> 2. mod_proxy_ajp (uses AJP protocol, comes bundled with httpd)
> 3. mod_jk (uses AJP, you must build this separately)
>
> Although mod_jk does not ship with httpd, it has more flexible
> features and tends to be more up-to-date because it has releases that
> aren't tied to httpd's schedule.
>
> > Do you recommend me to read
> > http://tomcat.apache.org/connectors-doc/reference/apache.html ?
> > I've found also
> > http://tomcat.apache.org/connectors-doc/reference/apache.html but
> > it seems to be outdated.
>
> Those are the same URLs and I believe it is up-to-date. I would only
> read this if you have chosen to use httpd with mod_jk: that's what the
> documentation is for. If you want to use mod_proxy_*, you should read
> the documentation for httpd here:
> http://httpd.apache.org/docs/2.2/mod/mod_proxy_http.html
> or
> http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html
>
> I really think you need to decide (or tell us) what your requirements
> are before you start charging-into a decision like adding a completely
> new component to your environment.
>
>
Connecting apache htttpd server with tomcat, can I run several tomcat
instances and run each http request in a different tomcat instance? I know
that this is not the tomcat philosophy, but I just want to know if it is
possible or is common this approach for this kind of situations.
My principal requirements are: stability (main concern), scalability,
serving concurrent requests (no more than 100 concurrent requests).
If possible: flexibility/maintainability.
I think that your option #4 is the appropriate in this situation.
Thanks a lot for your comments and suggestions!!
Regards,
Hernán
Re: Running not multithreaded application
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hernan,
On 12/14/11 7:15 PM, hernan wrote:
> On Wed, Dec 14, 2011 at 8:17 PM, Christopher Schultz <
>> What makes this "external" "program" non-multithreaded? Is it
>> actually not threadsafe?
>>
>> If you can't run it in the same process as Tomcat, then you'll
>> have to either use Runtime.exec or some type of wrapper around it
>> -- or have that process running completely separately (as a
>> daemon) and connect to it via sockets. Anything else requires
>> native code, which you definitely don't want.
>
> My external application is a java application that uses java
> wrapper (using JNI) for GLPK (written in ANSI C)
> (http://www.gnu.org/s/glpk/), and GLPK is not threadsafe. Yes, I
> will consider those alternatives, executing a new process when I
> receive the request (Runtime.exec) and a separated deamon receiving
> requests launching those processes.
So, you're already running native code, eh? Well, you have several
options IMO:
1. Run the thing as a separate process, wrapped in Java. This requires
that you run Runtime.exec() and call the Java wrapper you have.
I'm not entirely sure why you'd bother with the Java wrapper if you
were going to call-out to a separate program, but it's an option.
See #2 for caveats.
2. Run the thing as a separate process *directly*. That is, instead of
doing Runtime.exec("/path/to/java/wrapper"), you'd just do
Runtime.exec("/path/to/native/binary"). You'll get better performance
and will avoid the native code required to bridge from Java to
native, which is likely to improve stability.
On the other hand, Runtime.exec() is a monster, and you can deadlock
your thread(s) easily if you don't know what you are doing.
Runtime.exec() essentially requires 2 threads per call because you
have to monitor both stdout and stderr and consume them otherwise
you risk deadlock. You might want to use a wrapper library to improve
your chances.
3. Run the thing in-process with Tomcat, but use some kind of service
that isolates and serializes access to the non-threadsafe library.
You can do this with a singleton (or something like it) that has
a synchronized "run-GLPK" method: that will restrict callers such
that only one of them can use the library at a time.
I highly recommend that you try to acquire a lock using a timeout
instead of just blindly calling a synchronized method otherwise
you might end up in a deadlock situation if the library (or your
code) stalls at some point.
Another caveat: running JNI within a server process has inherent
risks of crashing the native module (if there is a bug in DLPK or
in the native wrapper around it) which will bring-down your whole
Tomcat service: that's obviously bad.
4. As I suggested before, run GLPK as a daemon process and communicate
with it via sockets or whatever. Has anyone written a GLPK-service?
So, perhaps the simplest thing to do is #3, but it has the most
runtime risks. The safest thing is to run as a separate process and
communicate via sockets, but that might require significant investment
in infrastructure (to build the service, then call-out to it).
Are there any other requirements? For example: do you need to be able
to handle multiple simultaneous incoming HTTP requests that all need
to use GLPK? Or, is this relatively rare? If you need high
concurrency, then option #3 simply isn't going to work unless the
operations are very fast (which I suspect they are not).
Do you have any idea how stable GLPK is? How about the native wrapper
in Java?
> Can I configure tomcat for running a new (or different) process for
> each request?
No. Tomcat runs in a single JVM, pretty much by definition. You can
get Tomcat to run a *servlet* as a new instance of the class that
defines it (by using SingleThreadModel) but that does not help you,
here, and is a deprecated capability anyway.
> or I have to run Apache HTTP Server and connect it to Tomcat?
That's not necessary, either, although it might make it easier to wrap
a service around GLPK with a simple set of CGI-BIN-style scripts
written in Bash, Perl, etc.
> If I have to run Apache HTTP Server which mechanism do I have to
> connect it with tomcat? using Jk connector is the standard way?
If you have to add httpd to the mix, you basically have 3 choices:
1. mod_proxy_http (uses HTTP protocol, comes bundled with httpd)
2. mod_proxy_ajp (uses AJP protocol, comes bundled with httpd)
3. mod_jk (uses AJP, you must build this separately)
Although mod_jk does not ship with httpd, it has more flexible
features and tends to be more up-to-date because it has releases that
aren't tied to httpd's schedule.
> Do you recommend me to read
> http://tomcat.apache.org/connectors-doc/reference/apache.html ?
> I've found also
> http://tomcat.apache.org/connectors-doc/reference/apache.html but
> it seems to be outdated.
Those are the same URLs and I believe it is up-to-date. I would only
read this if you have chosen to use httpd with mod_jk: that's what the
documentation is for. If you want to use mod_proxy_*, you should read
the documentation for httpd here:
http://httpd.apache.org/docs/2.2/mod/mod_proxy_http.html
or
http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html
I really think you need to decide (or tell us) what your requirements
are before you start charging-into a decision like adding a completely
new component to your environment.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7qEV4ACgkQ9CaO5/Lv0PB0UACeLpJDL59XZNyr/nUGFSOSYqoM
HWUAn3ToRjreYOkUKeCC6Z4Ma4ptXEA0
=Ql+v
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Running not multithreaded application
Posted by Pid <pi...@pidster.com>.
On 23/12/2011 02:05, hernan wrote:
>>
>>>>>> On 12/14/11 5:45 PM, hernan wrote:
>>>>>>> I'm using Tomcat 7.0 for developing a new application. A key
>>>>>>> component in the application have to run an external not
>>>>>>> multithreaded application.
>>>>>>>
>>>>>>> Since I'm not an experienced user in Tomcat, I wonder which
>>>>>>> implementation alternatives do you recommend for running my
>>>>>>> external application. I'm trying to avoid launch a new os process
>>>>>>> from java since I need the result of that process, so in this way
>>>>>>> I've to deal communicating two processes (may be using serializable
>>>>>>> objects using sockets).
>>>>>>
>>>>>> So, is this other program a Java program? Since you said
>>>>>> "serializable" you probably are talking about running another Java
>>>>>> "program".
>>>>>>
>>>>>> What makes this "external" "program" non-multithreaded? Is it actually
>>>>>> not threadsafe?
>>>>>>
>>>>>> If you can't run it in the same process as Tomcat, then you'll have to
>>>>>> either use Runtime.exec or some type of wrapper around it -- or have
>>>>>> that process running completely separately (as a daemon) and connect
>>>>>> to it via sockets. Anything else requires native code, which you
>>>>>> definitely don't want.
>>>>>
>>>>>
>>>>> My external application is a java application that uses java wrapper
>>>> (using
>>>>> JNI) for GLPK (written in ANSI C) (http://www.gnu.org/s/glpk/), and
>>>> GLPK is
>>>>> not threadsafe. Yes, I will consider those alternatives, executing a
>> new
>>>>> process when I receive the request (Runtime.exec) and a separated
>> deamon
>>>>> receiving requests launching those processes.
>>>>
>>>> Can you not import the application Jars and just interact with them
>>>> directly then? Why do you have to interact with it via system process?
>>>>
>>>
>>> If I do that, due to glpk is not threadsafe, a call to a method can crash
>>> tomcat.
>>
>> I don't know what glpk does, can you explain?
>
>
> glpk is a gnu library to solving some kind of mathematical problems
> http://www.gnu.org/software/glpk/
>
> You can use the library in c, and there exist wrappers for java, python and
> other programming languages
>
>
>
>>
>> I think you may be over thinking the thread safety issue.
>>
>> If multiple threads can't access the instances of the thing, thread
>> safety is not an issue.
>>
>> If the entire code block was instantiated inside a Servlet doGet
>> method with no external exposure or external scope, there is no
>> problem.
>>
>> Do you know why it is not thread safe?
>
> I know about some problems related to process memory
> allocation/deallocation because I've experienced them. The documentation
> says that is not thread safe.
Yes, but thread-safety is a very broad topic.
If the code does something weird like use a mmap'd file with a hard
coded path, then starting up separate processes won't help either.
> Why do you think that I'm over thinking thread safety issue?
In Java for example, code that is not inherently thread-safe can be used
safely in a multithreaded environment. The SimpleDateFormat class is a
good example of this.
Because it may be possible to use the code safely, if you take some
precautions. Understanding exactly why it is deemed "not thread safe"
would allow you do that.
Warning that the code is not thread-safe usually just means that the
author is telling you not to share use of that code *between* threads.
If the code is utilised entirely within the scope of a single thread
there is (usually) no issue. YMMV.
p
--
[key:62590808]
Re: Running not multithreaded application
Posted by hernan <hb...@gmail.com>.
>
> >>>> On 12/14/11 5:45 PM, hernan wrote:
> >>>>> I'm using Tomcat 7.0 for developing a new application. A key
> >>>>> component in the application have to run an external not
> >>>>> multithreaded application.
> >>>>>
> >>>>> Since I'm not an experienced user in Tomcat, I wonder which
> >>>>> implementation alternatives do you recommend for running my
> >>>>> external application. I'm trying to avoid launch a new os process
> >>>>> from java since I need the result of that process, so in this way
> >>>>> I've to deal communicating two processes (may be using serializable
> >>>>> objects using sockets).
> >>>>
> >>>> So, is this other program a Java program? Since you said
> >>>> "serializable" you probably are talking about running another Java
> >>>> "program".
> >>>>
> >>>> What makes this "external" "program" non-multithreaded? Is it actually
> >>>> not threadsafe?
> >>>>
> >>>> If you can't run it in the same process as Tomcat, then you'll have to
> >>>> either use Runtime.exec or some type of wrapper around it -- or have
> >>>> that process running completely separately (as a daemon) and connect
> >>>> to it via sockets. Anything else requires native code, which you
> >>>> definitely don't want.
> >>>
> >>>
> >>> My external application is a java application that uses java wrapper
> >> (using
> >>> JNI) for GLPK (written in ANSI C) (http://www.gnu.org/s/glpk/), and
> >> GLPK is
> >>> not threadsafe. Yes, I will consider those alternatives, executing a
> new
> >>> process when I receive the request (Runtime.exec) and a separated
> deamon
> >>> receiving requests launching those processes.
> >>
> >> Can you not import the application Jars and just interact with them
> >> directly then? Why do you have to interact with it via system process?
> >>
> >
> > If I do that, due to glpk is not threadsafe, a call to a method can crash
> > tomcat.
>
> I don't know what glpk does, can you explain?
glpk is a gnu library to solving some kind of mathematical problems
http://www.gnu.org/software/glpk/
You can use the library in c, and there exist wrappers for java, python and
other programming languages
>
> I think you may be over thinking the thread safety issue.
>
> If multiple threads can't access the instances of the thing, thread
> safety is not an issue.
>
> If the entire code block was instantiated inside a Servlet doGet
> method with no external exposure or external scope, there is no
> problem.
>
> Do you know why it is not thread safe?
>
I know about some problems related to process memory
allocation/deallocation because I've experienced them. The documentation
says that is not thread safe.
Why do you think that I'm over thinking thread safety issue?
Re: Running not multithreaded application
Posted by Pid * <pi...@pidster.com>.
On 15 Dec 2011, at 17:56, hernan <hb...@gmail.com> wrote:
> On Thu, Dec 15, 2011 at 12:27 PM, Pid <pi...@pidster.com> wrote:
>
>> On 15/12/2011 00:15, hernan wrote:
>>> On Wed, Dec 14, 2011 at 8:17 PM, Christopher Schultz <
>>> chris@christopherschultz.net> wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Hernán,
>>>>
>>>> On 12/14/11 5:45 PM, hernan wrote:
>>>>> I'm using Tomcat 7.0 for developing a new application. A key
>>>>> component in the application have to run an external not
>>>>> multithreaded application.
>>>>>
>>>>> Since I'm not an experienced user in Tomcat, I wonder which
>>>>> implementation alternatives do you recommend for running my
>>>>> external application. I'm trying to avoid launch a new os process
>>>>> from java since I need the result of that process, so in this way
>>>>> I've to deal communicating two processes (may be using serializable
>>>>> objects using sockets).
>>>>
>>>> So, is this other program a Java program? Since you said
>>>> "serializable" you probably are talking about running another Java
>>>> "program".
>>>>
>>>> What makes this "external" "program" non-multithreaded? Is it actually
>>>> not threadsafe?
>>>>
>>>> If you can't run it in the same process as Tomcat, then you'll have to
>>>> either use Runtime.exec or some type of wrapper around it -- or have
>>>> that process running completely separately (as a daemon) and connect
>>>> to it via sockets. Anything else requires native code, which you
>>>> definitely don't want.
>>>
>>>
>>> My external application is a java application that uses java wrapper
>> (using
>>> JNI) for GLPK (written in ANSI C) (http://www.gnu.org/s/glpk/), and
>> GLPK is
>>> not threadsafe. Yes, I will consider those alternatives, executing a new
>>> process when I receive the request (Runtime.exec) and a separated deamon
>>> receiving requests launching those processes.
>>
>> Can you not import the application Jars and just interact with them
>> directly then? Why do you have to interact with it via system process?
>>
>
> If I do that, due to glpk is not threadsafe, a call to a method can crash
> tomcat.
I don't know what glpk does, can you explain?
I think you may be over thinking the thread safety issue.
If multiple threads can't access the instances of the thing, thread
safety is not an issue.
If the entire code block was instantiated inside a Servlet doGet
method with no external exposure or external scope, there is no
problem.
Do you know why it is not thread safe?
p
> I can use glpk via a synchronized method, but I don't want to
> serialize the server requests, since I want run a fair service: "heavy"
> input have to wait more than a "light" one.
>
>
>>>>> I want to know which kind of approachs are used to deal with these
>>>>> type of situations.
>>>>
>>>> What about running in-process? Even if the class(es) is(are) not
>>>> threadsafe, you might be able to use separate instances from your
>>>> request processor threads.
>>
>> +1, see above.
>>
>>
>>> Can I configure tomcat for running a new (or different) process for each
>>> request?
>>
>> "configure"? Not really, you can write a Servlet to do that, if you
>> wanted to. (I wouldn't think that's a good idea, myself).
>>
>>
>>> or I have to run Apache HTTP Server and connect it to Tomcat?
>>
>> Why? How does that help?
>
>
> May be if there is some way to serve each http server request with a
> different tomcat service process (having a pool of tomcat processes). I
> know that is not the tomcat philosophy, but I just wonder if it is feasible
> via apache httpd and tomcat configurations.
>
>
>>
>>> If I have to run Apache HTTP Server which mechanism do I have to connect
>> it with
>>> tomcat? using Jk connector is the standard way?
>>
>> mod_jk, or mod_proxy_http or mod_proxy_ajp.
>>
>>
>>> Do you recommend me to read
>>> http://tomcat.apache.org/connectors-doc/reference/apache.html ? I've
>> found
>>> also http://tomcat.apache.org/connectors-doc/reference/apache.html but
>> it
>>> seems to be outdated.
>>
>> How is that related to your problem?
>>
>>
>> p
>>
>>> Thanks for your response!
>>>
>>> Regards,
>>> Hernán
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Running not multithreaded application
Posted by hernan <hb...@gmail.com>.
On Thu, Dec 15, 2011 at 12:27 PM, Pid <pi...@pidster.com> wrote:
> On 15/12/2011 00:15, hernan wrote:
> > On Wed, Dec 14, 2011 at 8:17 PM, Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hernán,
> >>
> >> On 12/14/11 5:45 PM, hernan wrote:
> >>> I'm using Tomcat 7.0 for developing a new application. A key
> >>> component in the application have to run an external not
> >>> multithreaded application.
> >>>
> >>> Since I'm not an experienced user in Tomcat, I wonder which
> >>> implementation alternatives do you recommend for running my
> >>> external application. I'm trying to avoid launch a new os process
> >>> from java since I need the result of that process, so in this way
> >>> I've to deal communicating two processes (may be using serializable
> >>> objects using sockets).
> >>
> >> So, is this other program a Java program? Since you said
> >> "serializable" you probably are talking about running another Java
> >> "program".
> >>
> >> What makes this "external" "program" non-multithreaded? Is it actually
> >> not threadsafe?
> >>
> >> If you can't run it in the same process as Tomcat, then you'll have to
> >> either use Runtime.exec or some type of wrapper around it -- or have
> >> that process running completely separately (as a daemon) and connect
> >> to it via sockets. Anything else requires native code, which you
> >> definitely don't want.
> >
> >
> > My external application is a java application that uses java wrapper
> (using
> > JNI) for GLPK (written in ANSI C) (http://www.gnu.org/s/glpk/), and
> GLPK is
> > not threadsafe. Yes, I will consider those alternatives, executing a new
> > process when I receive the request (Runtime.exec) and a separated deamon
> > receiving requests launching those processes.
>
> Can you not import the application Jars and just interact with them
> directly then? Why do you have to interact with it via system process?
>
If I do that, due to glpk is not threadsafe, a call to a method can crash
tomcat. I can use glpk via a synchronized method, but I don't want to
serialize the server requests, since I want run a fair service: "heavy"
input have to wait more than a "light" one.
> >>> I want to know which kind of approachs are used to deal with these
> >>> type of situations.
> >>
> >> What about running in-process? Even if the class(es) is(are) not
> >> threadsafe, you might be able to use separate instances from your
> >> request processor threads.
>
> +1, see above.
>
>
> > Can I configure tomcat for running a new (or different) process for each
> > request?
>
> "configure"? Not really, you can write a Servlet to do that, if you
> wanted to. (I wouldn't think that's a good idea, myself).
>
>
> > or I have to run Apache HTTP Server and connect it to Tomcat?
>
> Why? How does that help?
May be if there is some way to serve each http server request with a
different tomcat service process (having a pool of tomcat processes). I
know that is not the tomcat philosophy, but I just wonder if it is feasible
via apache httpd and tomcat configurations.
>
> > If I have to run Apache HTTP Server which mechanism do I have to connect
> it with
> > tomcat? using Jk connector is the standard way?
>
> mod_jk, or mod_proxy_http or mod_proxy_ajp.
>
>
> > Do you recommend me to read
> > http://tomcat.apache.org/connectors-doc/reference/apache.html ? I've
> found
> > also http://tomcat.apache.org/connectors-doc/reference/apache.html but
> it
> > seems to be outdated.
>
> How is that related to your problem?
>
>
> p
>
> > Thanks for your response!
> >
> > Regards,
> > Hernán
> >
>
Re: Running not multithreaded application
Posted by Pid <pi...@pidster.com>.
On 15/12/2011 00:15, hernan wrote:
> On Wed, Dec 14, 2011 at 8:17 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hernán,
>>
>> On 12/14/11 5:45 PM, hernan wrote:
>>> I'm using Tomcat 7.0 for developing a new application. A key
>>> component in the application have to run an external not
>>> multithreaded application.
>>>
>>> Since I'm not an experienced user in Tomcat, I wonder which
>>> implementation alternatives do you recommend for running my
>>> external application. I'm trying to avoid launch a new os process
>>> from java since I need the result of that process, so in this way
>>> I've to deal communicating two processes (may be using serializable
>>> objects using sockets).
>>
>> So, is this other program a Java program? Since you said
>> "serializable" you probably are talking about running another Java
>> "program".
>>
>> What makes this "external" "program" non-multithreaded? Is it actually
>> not threadsafe?
>>
>> If you can't run it in the same process as Tomcat, then you'll have to
>> either use Runtime.exec or some type of wrapper around it -- or have
>> that process running completely separately (as a daemon) and connect
>> to it via sockets. Anything else requires native code, which you
>> definitely don't want.
>
>
> My external application is a java application that uses java wrapper (using
> JNI) for GLPK (written in ANSI C) (http://www.gnu.org/s/glpk/), and GLPK is
> not threadsafe. Yes, I will consider those alternatives, executing a new
> process when I receive the request (Runtime.exec) and a separated deamon
> receiving requests launching those processes.
Can you not import the application Jars and just interact with them
directly then? Why do you have to interact with it via system process?
>>> I want to know which kind of approachs are used to deal with these
>>> type of situations.
>>
>> What about running in-process? Even if the class(es) is(are) not
>> threadsafe, you might be able to use separate instances from your
>> request processor threads.
+1, see above.
> Can I configure tomcat for running a new (or different) process for each
> request?
"configure"? Not really, you can write a Servlet to do that, if you
wanted to. (I wouldn't think that's a good idea, myself).
> or I have to run Apache HTTP Server and connect it to Tomcat?
Why? How does that help?
> If I have to run Apache HTTP Server which mechanism do I have to connect it with
> tomcat? using Jk connector is the standard way?
mod_jk, or mod_proxy_http or mod_proxy_ajp.
> Do you recommend me to read
> http://tomcat.apache.org/connectors-doc/reference/apache.html ? I've found
> also http://tomcat.apache.org/connectors-doc/reference/apache.html but it
> seems to be outdated.
How is that related to your problem?
p
> Thanks for your response!
>
> Regards,
> Hernán
>
--
[key:62590808]
Re: Running not multithreaded application
Posted by hernan <hb...@gmail.com>.
On Wed, Dec 14, 2011 at 8:17 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hernán,
>
> On 12/14/11 5:45 PM, hernan wrote:
> > I'm using Tomcat 7.0 for developing a new application. A key
> > component in the application have to run an external not
> > multithreaded application.
> >
> > Since I'm not an experienced user in Tomcat, I wonder which
> > implementation alternatives do you recommend for running my
> > external application. I'm trying to avoid launch a new os process
> > from java since I need the result of that process, so in this way
> > I've to deal communicating two processes (may be using serializable
> > objects using sockets).
>
> So, is this other program a Java program? Since you said
> "serializable" you probably are talking about running another Java
> "program".
>
> What makes this "external" "program" non-multithreaded? Is it actually
> not threadsafe?
>
> If you can't run it in the same process as Tomcat, then you'll have to
> either use Runtime.exec or some type of wrapper around it -- or have
> that process running completely separately (as a daemon) and connect
> to it via sockets. Anything else requires native code, which you
> definitely don't want.
My external application is a java application that uses java wrapper (using
JNI) for GLPK (written in ANSI C) (http://www.gnu.org/s/glpk/), and GLPK is
not threadsafe. Yes, I will consider those alternatives, executing a new
process when I receive the request (Runtime.exec) and a separated deamon
receiving requests launching those processes.
> > I want to know which kind of approachs are used to deal with these
> > type of situations.
>
> What about running in-process? Even if the class(es) is(are) not
> threadsafe, you might be able to use separate instances from your
> request processor threads.
Can I configure tomcat for running a new (or different) process for each
request? or I have to run Apache HTTP Server and connect it to Tomcat? If I
have to run Apache HTTP Server which mechanism do I have to connect it with
tomcat? using Jk connector is the standard way?
Do you recommend me to read
http://tomcat.apache.org/connectors-doc/reference/apache.html ? I've found
also http://tomcat.apache.org/connectors-doc/reference/apache.html but it
seems to be outdated.
Thanks for your response!
Regards,
Hernán
Re: Running not multithreaded application
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hernán,
On 12/14/11 5:45 PM, hernan wrote:
> I'm using Tomcat 7.0 for developing a new application. A key
> component in the application have to run an external not
> multithreaded application.
>
> Since I'm not an experienced user in Tomcat, I wonder which
> implementation alternatives do you recommend for running my
> external application. I'm trying to avoid launch a new os process
> from java since I need the result of that process, so in this way
> I've to deal communicating two processes (may be using serializable
> objects using sockets).
So, is this other program a Java program? Since you said
"serializable" you probably are talking about running another Java
"program".
What makes this "external" "program" non-multithreaded? Is it actually
not threadsafe?
If you can't run it in the same process as Tomcat, then you'll have to
either use Runtime.exec or some type of wrapper around it -- or have
that process running completely separately (as a daemon) and connect
to it via sockets. Anything else requires native code, which you
definitely don't want.
> I want to know which kind of approachs are used to deal with these
> type of situations.
What about running in-process? Even if the class(es) is(are) not
threadsafe, you might be able to use separate instances from your
request processor threads.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7pLp0ACgkQ9CaO5/Lv0PAjUwCgtac2NvrAvv+BnyOXmpZ7gUGN
DBQAn0QmyKonMzuGh6gpzvFaQuGBVqgd
=ZFKJ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org