Out-of-process servlet

[sloan]

I'm using Tomcat 4.1.12 on a Win2K server to host a servlet which uses
JNI to call a DLL. I would like to run multiple instances of this
servlet calling separate instances of the DLL. That part is no problem
simply by giving each instance a unique name (both servlet class and
DLL). However, I'd like to run each instance in its own process space
because of the memory requirements of the DLL.

So far, the only way I've found to do this is to run multiple
instances of Tomcat. That's simple enough using the CATALINA_BASE
setting and launching multiple copies of the server. However, it would
be simpler if I could run one instance of Tomcat and designate certain
parts of it to run out of process, say at the context, host, or engine
level.

Is it possible to set a context within the Tomcat server to run in its
own process space?

I apologize if this is off-topic for the group. In searching the
archives, it seemed that most Tomcat config questions ended up here.
If there's a better place, let me know.

 

[William Brogden]

I'm using Tomcat 4.1.12 on a Win2K server to host a servlet which uses
JNI to call a DLL. I would like to run multiple instances of this
servlet calling separate instances of the DLL. That part is no problem
simply by giving each instance a unique name (both servlet class and
DLL). However, I'd like to run each instance in its own process space
because of the memory requirements of the DLL.

So far, the only way I've found to do this is to run multiple
instances of Tomcat. That's simple enough using the CATALINA_BASE
setting and launching multiple copies of the server. However, it would
be simpler if I could run one instance of Tomcat and designate certain
parts of it to run out of process, say at the context, host, or engine
level.

Is it possible to set a context within the Tomcat server to run in its
own process space?

I apologize if this is off-topic for the group. In searching the
archives, it seemed that most Tomcat config questions ended up here.
If there's a better place, let me know.

I suspect your architecture is all wrong and you should go to some
sort of distributed processes communicating with a single servlet.
Anyway, try this question on JavaRanch - possibly the servlets
forum or the distributed Java forum.
http://www.javaranch.com/
Bill

 

[nos]

I'm using Tomcat 4.1.12 on a Win2K server to host a servlet which uses
JNI to call a DLL. I would like to run multiple instances of this
servlet calling separate instances of the DLL. That part is no problem
simply by giving each instance a unique name (both servlet class and
DLL). However, I'd like to run each instance in its own process space
because of the memory requirements of the DLL.

So far, the only way I've found to do this is to run multiple
instances of Tomcat. That's simple enough using the CATALINA_BASE
setting and launching multiple copies of the server. However, it would
be simpler if I could run one instance of Tomcat and designate certain
parts of it to run out of process, say at the context, host, or engine
level.

Is it possible to set a context within the Tomcat server to run in its
own process space?

I apologize if this is off-topic for the group. In searching the
archives, it seemed that most Tomcat config questions ended up here.
If there's a better place, let me know.

What is the nature of the "dll", if you make it re-entrant you will
only need one copy.

 

[sloan]

I suspect your architecture is all wrong and you should go to some
sort of distributed processes communicating with a single servlet.
Anyway, try this question on JavaRanch - possibly the servlets
forum or the distributed Java forum.

I'm certainly open to suggestion on different architectures. One
obvious way to handle it is to build the separate copies as
independent processes with their own listeners (either HTTP or some
other calling process). I was using servlets to take advantage of the
robust listener code already built into the server, but if we have to
jump through too many hoops to put our processes in separate memory
space, then an architecture change will be called for.

 

[sloan]

What is the nature of the "dll", if you make it re-entrant you will
only need one copy.

Thanks for the feedback. Unfortunately the DLL is fixed and we cannot
change it. It is not re-entrant, but even if it were, we would be left
with the same memory problems with all the calls coming from servlets in
the same instance of Tomcat. Whether we use one re-entrant DLL or multiple
uniquely named copies, the memory problems of the calling process are the
same as far as I can tell.

The DLL takes a call which initializes it using certain parameters, and
subsequent calls then operate on that initialized set. This is analogous
to an initialization which specifies a data set and loads it into memory
and subsequent calls operate on that data set. The initialization takes
considerable resources, both processing time and memory, so once a DLL is
initialized for a certain set, we want to maintain that for queries rather
than re-initializing on each query. We have a number of different
initialization parameters which are relevant at any given time, which leads
to the requirement to have a number of already-initialized DLLs resident in
memory.

 

[William Brogden]

"nos" <[email protected]> wrote in message

Thanks for the feedback. Unfortunately the DLL is fixed and we cannot
change it. It is not re-entrant, but even if it were, we would be left
with the same memory problems with all the calls coming from servlets in
the same instance of Tomcat. Whether we use one re-entrant DLL or multiple
uniquely named copies, the memory problems of the calling process are the
same as far as I can tell.

The DLL takes a call which initializes it using certain parameters, and
subsequent calls then operate on that initialized set. This is analogous
to an initialization which specifies a data set and loads it into memory
and subsequent calls operate on that data set. The initialization takes
considerable resources, both processing time and memory, so once a DLL is
initialized for a certain set, we want to maintain that for queries rather
than re-initializing on each query. We have a number of different
initialization parameters which are relevant at any given time, which leads
to the requirement to have a number of already-initialized DLLs resident in
memory.

Sounds like "distributed Java" to me - If you make a simple Java application
that holds one DLL instance and can communicate with some sort of
coordinating agent, you can keep a lot of these going - each in its own
JVM/memory space - and there is no reason they couldn't be spread
over a number of machines - look! we just invented GRID computing.
JavaSpaces would be ideal for the coordinating agent.
Bill