Hi Taylor, Comments in line...
Taylor Gautier wrote: > 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? Isn't this up to the embedder (-Xmx=?)? I think having it run as an outside process actually increases memory because now you have 2 JVMs running instead of one. In an embedded instance, there is only the overhead of a single JVM. > 2) CPU. Same as above, but for CPU. If I am running on a single machine, it takes more CPU to run 2 JVMs than one (again JVM overhead). Even if there were no overhead, then as a worst case, the same CPU utilization should be for inside and outside the embedded process. Also, perhaps I want a lightwieght pluggable Geronimo instance to manage the Lifecycle of a Terracotta instance...we are talking just the G kernel and the TC embedded server - its a valid use case. > 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)? > Shutting down the embedding container based on an exception in TC is not a good idea. G is simply a kernel that manages life cycle and a failure typically means the GBean stops. One of the capabilities Geronimo has is to do notifications based on failures (i.e. paging, logging, email). Exiting the JVM prevents this from occurring and would likely cause IT support people to cringe. ;-) I think a possible work around for this is to signal the GBean with a callback interface and the Gbean can decide whether to reset the classloader and restart or to fully abort. Thus a standalone TC server can exit the VM based on the callback raised error, and an embedded container can decide otherwise. A graceful shutdown of TC would make this simple. > 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? If TC can be started from the command line with a couple of scripts, why is it not plausible to launch/stop it from an application server? The beauty of the simplicity model is that I can point a Geronimo console at the TC plugin repo and have a TC server fully deployed and running within the G model in under 1 minute. This is likened to the Eclipse model. Imagine if you had to install your Eclipse plugins as a command line interface that runs outside of Eclipse. ;-) Jeff > > 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 _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
