Jeff,
On the flip side, I am not sure it completely makes sense for the server
to be embedded. I see a few long-term issues with this strategy, aside
from the coding and control part.
1) Memory. Should cluster memory compete with the managent server for
heap? Is there a lot loaded in the management that this would be an issue?
2) CPU. Same as above, but for CPU.
3) Should the management console exiting either normally or abnormally
cause the cluster to unavailable (as an abnormal mgmt exit would mean by
definition that an embedded tc server would also shutdown)?
I think Tim mentioned that the idea of the plugin was for simplicity,
and not really intended for a full-fledged deployment model. If that's
the case, then the above are mostly mitgated by this. Thoughts?
Jeff Genender wrote:
Orion Letizi wrote:
Jeff,
There's probably no immediate recourse for making the server behave
the way you want it to in-process.
Well...we can agree to disagree on this ;-)
Geronimo must have full control over the server lifecycle to run the
server as a plugin. Doing it out-of-process is going to be difficult at
best, is kludgey, and is going to cause a lot more code to monitor the
status of the server, as well as create a host of other problems. I am
not currently willing to integrate the server component as a plugin
without a clean start/stop.
IMHO exiting the JVM because TC currently does not shut down in a clean
manner is just a heavy handed treatment to a problem that I believe is
going to have to be dealt with in the future.
But, there are some utilities that we use in tests that make it
pretty easy to control a server externally. Take a look at
com.tc.objectserver.control.ExtraProcessServerControl (it's in trunk/
code/base/simulator).
If you don't like the ServerControl abstraction, you can use the more
general purpose tool com.tc.process.LinkedJavaProcess (it's in trunk/
code/base/common/src). Actually, as I write this, I think this is
the better option. It actually ships in tc.jar, so you can compile
against it. The way it works is that a spawned java process has a
ping back to the parent java process and, if that parent goes away,
it will kill itself.
I tried using the LinkedJavaProcess and although it worked to certain
extent, I would have to write a significant amount of status checking
code. It's simply not worth the trouble.
If we can't get this embeddable at this stage, I am willing to abandon
the server plugin and concentrate solely on the client side integration.
We can let people start/stop Terracotta from the binary download. Its
kind of too bad because its cool to see how the TC server starts from a
plugin...if only we could stop it ;-)
Thanks for letting me know the status.
Jeff
--Orion
On Sep 4, 2007, at 2:17 PM, Jeff Genender wrote:
Tim Eck wrote:
That JIRA is really talking about shutdown from the client (L1)
side (as
opposed to the terracotta server (L2) side).
How does TCStop help? It's still going to end up calling
System.exit() as
far as I can tell -- and doesn't really jive with an embedded L2
server.
Currently I am calling the TCServer.stop() because TCStop is calling
system.exit() - and we can't have that ;-)
The stop() shuts down everything, but the dsoServer is still
hanging and
listening on 9510. I even wrote my own TCGeronimoServerImpl which
essentially is the same as TCServer, but I can control the the
dsoServer.stop() and quickStop() calls. Those still leave 9510
hanging,
so it appears its something deeper.
Graceful shutdown of the TC server has been known to be busted for
quite
awhile. Seems like a good opportunity to clean that up?
+1
Jeff
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:tc-dev-
[EMAIL PROTECTED] On Behalf Of Fiona O'Shea
Sent: Tuesday, September 04, 2007 12:42 PM
To: Gary Keim
Cc: [email protected]
Subject: Re: [tc-dev] Embedding Terracotta (Geronimo plugin)
FYI
Updated: https://jira.terracotta.org/jira/browse/CDV-406 to track
progress
of this issue.
Fiona
----- Original Message -----
From: "Gary Keim" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, September 4, 2007 12:17:55 PM (GMT-0800)
America/Los_Angeles
Subject: Re: [tc-dev] Embedding Terracotta (Geronimo plugin)
Jeff,
There are problems with graceful shutdown:
https://jira.terracotta.org/jira/browse/DEV-406
So, in DistributedObjectServer.stop you'll see that really, it won't
stop.
For now, I think System.exec/TCStop is the way to go if you need
full
control.
Gary
----- Original Message -----
From: "Jeff Genender" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, September 04, 2007 10:59 AM
Subject: Re: [tc-dev] Embedding Terracotta (Geronimo plugin)
Anyone have an idea?
Jeff
Jeff Genender wrote:
ok...I may be getting my ports mixed up...looks like its 9510
that is
not shut down...and it is indeed the DSOServer.
Thanks,
Jeff
Jeff Genender wrote:
Ok...if I am not mistaken (and I may very well be)...I need the
ability
to shut down the dsoServer from the TCServerImpl. I think
this may
give
me what I want...
Anyone game to make this change? (Am I right in my assumption?)
Thanks,
Jeff
Jeff Genender wrote:
Hi folks,
I have made tremendous progress on the Terracotta server
plugin for
Geronimo. It installs from a repository and I can start the
server
just
fine within Geronimo.
But the problem I am having now is the stop. I am unable to use
the
TCStop because it does a full shutdown which ultimately ends
with a
System.exit(), which certainly is not good for embedded
implementations,
since it shuts down Geronimo too :-(
Therefore I went to save the server object when I created it
and I
just
called stop() when I want to shut down the TCServer. This
effectively
stops the server on 9510, but it leaves the 9520 (JMXServer)
server
running. But I need to shut that down too. Basically, I
want to
do
the
equivalent of a shutdown() without the System.exit().
Ideas on how to do this?
Thanks,
Jeff
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
