Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: [equinox-dev] Question on programatic close of the runtime 
Hi!

You can just go to:

https://dev.eclipse.org/mailman/listinfo/equinox-dev

to unsubscribe from the list.

HTH,
Martin


On 12.03.10 21:30, cpintsch@xxxxx wrote:


Hello,
Please stop sending me emails!!!!!!!!!!!!!!!!!!!!!!!!!
Take me out of your mailing list.
pilo@xxxxxxxx



Thomas Watson <tjwatson@xxxxxxxxxx> a écrit :



Why are you using the -console option? Seems like you would not really
want something on a cluster to be running in console mode. I am wondering
who actually would run commands on this console. I suggest you look at
the
org.eclipse.osgi.framework.console.ConsoleSession service in 3.6 if you
need a remote console for which you want more control over. When you
register a ConsoleSession service a new console will be started for your
ConsoleSession. You will have control over what provides the input and
output for the console session (use System.in/out, use a socket,
provide a
web UI, provide a console RCP view etc.). Then when you want the session
to end you simply unregister your ConsoleSession. If a bundle provides
the
console session service then the session will automatically get
cleaned up
when stopping the system bundle because all bundles will be stopped which
causes all services registered by bundles to be unregistered.

Unfortunately the built-in console session that gets used with the
-console
option does not automatically close when the framework is shutdown. This
is because we have some support in the console for running commands even
after the framework has shutdown and we leave this session open for that
purpose. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=279562 for
more
details.

Tom




|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|

|<Daniel.Stucky@xxxxxxxxxxx> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|

|<equinox-dev@xxxxxxxxxxx> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|

|03/12/2010 11:15 AM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|

|AW: [equinox-dev] Question on programatic close of the runtime |
>--------------------------------------------------------------------------------------------------------------------------------------------------|






Hi all,

our application (BTW: we are talking about SMILA) is a backend server,
with
instances running on a cluster. What do you suggest to remotely shutdown
the OSGi instances on each cluster node?

We cannot expect an administrator to log on every machine and to exit the
OSGI console by typing "close".

Therefore I had the idea to provide this functionality via HTTP. So
it's an
external call that stops bundle zero and after a configurable timeout
calls
System.exit() (hopefully giving the runtime enough time to savely stop
all
bundles). So the System.exit() is done on purpose by an administrator.

One way of connecting remotely would be to use telnet and then send a
close
command to the OSGi console. But this is cumbersome. Is this "safer" than
my approach as after Framework.close() this does also call
System.exit() ?

Bye,
Daniel


-----Ursprüngliche Nachricht-----
Von: equinox-dev-bounces@xxxxxxxxxxx [
mailto:equinox-dev-bounces@xxxxxxxxxxx] Im Auftrag von Neil Bartlett
Gesendet: Freitag, 12. März 2010 17:54
An: Equinox development mailing list
Betreff: Re: [equinox-dev] Question on programatic close of the runtime

Tim,

I agree but it's a matter of who is responsible for doing this. The
launcher code that created the framework and started it should be
responsible for shutting down the VM, after calling
Framework.waitForStop(). If a bundle calls System.exit() then it is
assuming too much about the environment in which it is deployed.

Neil

On Fri, Mar 12, 2010 at 4:47 PM, Tim Diekmann <tdiekman@xxxxxxxxx> wrote:

Hi,

while calling stop() on the system bundle is the correct and recommended

approach, it is not always sufficient in production environments.


The framework will only end if the main() method that started it runs
out

or someone calls System.exit(). However, for the main method to end, all
non-daemon threads have to be ended first. Bundles may have started
non-daemon threads. If you have started Equinox with the console enabled
that would be difficult and you continue to have a process lingering
around
and no OSGi framework.


System.exit() is the safest choice to ensure that the process has died.

Keep in mind that on shutdown Equinox is persisting its state and a call

to System.exit() during that phase may cause cache corruption.


  Tim.

"It is a simple task to make things complex, but a complex task to make

them simple."

 -- Fortune Cookie

On Mar 12, 2010, at 2:34 AM, Neil Bartlett wrote:


Daniel,

Stopping bundle zero is not a hack; this is the normal way to
programmatically shutdown OSGi. However:

1) There is no need to check that the bundle is active first. Calling
stop() on an already stopped bundle simply has no effect (likewise
calling start() on an already active bundle has no effect).

2) There should be no need to wait for the framework to stop and then
call System.exit(). Exiting the JVM should be the responsibility of
whoever created and started the framework, i.e. the launcher. Calling
System.exit() directly from within a bundle will cause big problems if
your bundle is deployed to a framework embedded in a larger system,
e.g. an application server.

In other words, the code could be as simple as this:

   _componentContext.getBundleContext().getBundle(0).stop();

Regards,
Neil

On Fri, Mar 12, 2010 at 10:16 AM, <Daniel.Stucky@xxxxxxxxxxx> wrote:

Hi all,



I would like to expose the functionality to close the Equinox runtime

via an

HTTP request. Therefore I have implemented a Jetty ContextHandler
as an
DeclarativeService. I used the FrameworkCommandProvider as an example

on how

to close the runtime, but I was not able to get access to the
Framework
class to call method close() on it.



I came up with a workaround for that, which is basically like this:



Bundle bundle = _componentContext.getBundleContext().getBundle(0);

if (bundle.getState() == Bundle.ACTIVE) {

bundle.stop();

 while (bundle.getState() != Bundle.RESOLVED) {

                // WAIT N milliseconds and REPEAT at most M times

 }

}

 System.exit(0);





This works fine for me, although it seems to be a hack stopping bundle

with

Id 0. Are there better ways to achieve my goal ? Are there any ways to

get

access to the Framework class ?





Bye,

Daniel

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev



_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev






_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Back to the top