A very similar architecture would be offered by using JMS (say openjms
or activeMQ;
we've been using the latter; check for others at http://java-source.net/open-source/jms
).
In this case, there is a "message broker" which runs separately.
At the moment, we're using it on one development machine, but we fully
expect
to be using it across multiple machines, integrating both Tomcat-based
apps
as well as other non-Tomcat-based (Java) applications.
We ensure that it is started before any of the webapps start. We're
doing
this manually now, but shortly we'll be doing it by running it as a
system service.
An excellent place to start is
http://java.sun.com/products/jms/
http://java.sun.com/products/jms/tutorial/
We are only using Java clients, but one of the advantages of JMS is
that one can
utilize a wide variety of other standards-based clients.
--Ken
On Oct 9, 2008, at 4:36 AM, André Warnier wrote:
Leon Rosenberg wrote:
On Thu, Oct 9, 2008 at 9:59 AM, André Warnier <[EMAIL PROTECTED]> wrote:
I realise that this can be done via e.g. an external DB.
It could also probably be done, most portably, by creating an
entirely
separate application accessed via HTTP calls e.g. (à la "Amazon
DB" ?).
But it looks as if "within the same container", it would be much
more
efficient if kept in local memory, and avoiding overhead like TCP/
IP or JDBC
or RMI.
Not being an expert in any of the underlying matters, I would just
like to
know from the eperts here, but preferably without too many
difficult words
like "classloader" and "dispatchers", if this is in theory
possible/allowed,
if it could be done in such a way as to be portable to a different
container
etc..
Well, it is possible by placing stuff in shared/lib and access it
from
different contextes, but it will make your life extremely
complicated,
especially if you start to reload applications on the fly, probably
causing an outofmemory exception at some point.
On the other side an rmi connection on the local machine is extremely
cheap (same applies to corba), if you make one call to rmi (or corba)
in one request to the application you won't even be able to measure
the transport overhead (far below 1 ms), and taking in account that
transport from browser to server is much much slower, you can ignore
the overhead. The overhead of http or soap is much higher due to
larger footprint of the call, parsing, connection issues (you have to
reconnect or handle keep alives yourself) and so on.
Behind your rmi service you can have an external db or just a hashmap
(concurrent one) or whatever serves best.
To sum it up, the TOC (total cost of ownership) of an RMI service are
much much lower as of most other solutions.
Many thanks.
So, assuming that I am now convinced by RMI (Remote Method
Invocation ?), how would such a scheme be implemented ?
Are you talking about a separate daemon, running on the same host,
which would "offer RMI services" to all these webapps ?
Or would this "thing" be living inside Tomcat ? If so, what kind of
"thing" would this be ? It would, I guess, have to start before the
webapps do, load its original data, then remain there waiting for
client webapp RMI calls, yes ?
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
