You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2006/03/11 20:35:25 UTC
Got a problem running felix in production mode
Looks like the standard out log file fills up with ...
-> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> ->
-> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> -
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> ->
-> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> ->
-> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> -
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> ->
-> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> ->
-> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> -
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> ->
-> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> ->
-> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> -
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> ->
-> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> ->
It keeps on filling and filling ... it will fill a disk if you let it.
How can we disable
this shell in production mode?
Alex
Re: Got a problem running felix in production mode
Posted by Herko ter Horst <he...@terhorst.net>.
> One thing is for sure, we do not have to all agree on and use a single
> main...it is perfectly reasonable to have different mains for different
> purposes.
As Marcel indicated I am working on a small set of APIs that should help
making your own "Main" easier. The API provides abstractions for
Launchers and FrameworkContexts.
Launchers capture knowledge on how to start a particular framework
implementation. I currently have implementations for Felix, Equinox and
Knopflerfish 2.
FrameworkContext provide a way to interact with specific environments
that an OSGi framework might live in. I current have implementations for
regular Java applications, JNLP/WebStart applications, services/daemons
(based on Apache Daemon) and servlets (i.e. run the framework within a
Servlet container and make that servlet container available as
HttpService to the framework). I'm currently busy cleaning up the
documentation, so expect a release soonish.
The API is currently based on the assumption that a single
management-type bundle will control the actual application(s) to be ran
on the framework, but this could be extended in the future.
Cheers,
Herko ter Horst
Re: Got a problem running felix in production mode
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Marcel Offermans wrote:
> The reason why we use our own main is that we do not want to use any property
> file. The properties that must be set are hardcoded in the code. The second
> reason is that we have (recently) added shutdown hooks to make sure the
> framework is shutdown cleanly when someone ends the process with Ctrl-C.
>
Even though the shutdown hooks might not be completely portable across
all Java platforms, this is something we could possibly put into the
standard Main or we could create an extended Main.
One thing is for sure, we do not have to all agree on and use a single
main...it is perfectly reasonable to have different mains for different
purposes.
-> richard
Re: Got a problem running felix in production mode
Posted by Marcel Offermans <ma...@xs4all.nl>.
On Sunday 12 March 2006 17:30, Richard S. Hall wrote:
> The standard Main is overall pretty simplistic, but it does allow you to
> specify the location of the config.properties file using a system
> property, so it is always possible to have a production
> config.properties file too that you select via a system property when
> you run in production mode.
The reason why we use our own main is that we do not want to use any property
file. The properties that must be set are hardcoded in the code. The second
reason is that we have (recently) added shutdown hooks to make sure the
framework is shutdown cleanly when someone ends the process with Ctrl-C.
But there are obviously many ways to start the framework. I know Herko ter
Horst is doing some work in this area too (not limited to Felix).
Greetings, Marcel
Re: Got a problem running felix in production mode
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alex Karasulu wrote:
> Richard S. Hall wrote:
>> Marcel Offermans wrote:
>>> We are using a custom "main" class that bootstraps the framework and
>>> installs the basic bundles (everything up to and including the
>>> "management agent"). This leaves the system in a state similar to
>>> what an initial provisioning implementation would do.
>>>
>>> We wrap this "main" class in a runnable jar that sets up the
>>> classpath to include the Felix jars.
>>
>> The standard Main is overall pretty simplistic, but it does allow you
>> to specify the location of the config.properties file using a system
>> property, so it is always possible to have a production
>> config.properties file too that you select via a system property when
>> you run in production mode.
>
> I'll try to get to it but I think what needs to be done here is ...
>
> (1) For UNIX installations to write a custom init script instead of
> the default one that is generated
> by the installer plugin and have that set two things:
> - the configuration file used should be set to production.properties
> - the profile to be used must be set to "production" so the default
> (debug mode based) profile is not
> used with the shell bundles in it
>
> (2) For Windows installations we need to modify the custom inno.iss
> file to set the system properties
> for the shell service so that ...
> - the configuration file used should be set to production.properties
> - the profile to be used must be set to "production" so the default
> (debug mode based) profile is not
> used with the shell bundles in it
Sounds good.
> So as you can see we need some environment property to be set for both
> cases to do the same things. Now is
> it possible that the profile can be chosen inside the
> config.properties? If so then I do not need a second
> property to select the profile.
Yes, you can specify the profile inside of the configuration properties
file. If you look at the current config.properties file you can see an
example in there that is commented out.
-> richard
Re: Got a problem running felix in production mode
Posted by Alex Karasulu <ao...@bellsouth.net>.
Richard S. Hall wrote:
> Marcel Offermans wrote:
>> We are using a custom "main" class that bootstraps the framework and
>> installs the basic bundles (everything up to and including the
>> "management agent"). This leaves the system in a state similar to
>> what an initial provisioning implementation would do.
>>
>> We wrap this "main" class in a runnable jar that sets up the
>> classpath to include the Felix jars.
>
> The standard Main is overall pretty simplistic, but it does allow you
> to specify the location of the config.properties file using a system
> property, so it is always possible to have a production
> config.properties file too that you select via a system property when
> you run in production mode.
I'll try to get to it but I think what needs to be done here is ...
(1) For UNIX installations to write a custom init script instead of the
default one that is generated
by the installer plugin and have that set two things:
- the configuration file used should be set to production.properties
- the profile to be used must be set to "production" so the default
(debug mode based) profile is not
used with the shell bundles in it
(2) For Windows installations we need to modify the custom inno.iss file
to set the system properties
for the shell service so that ...
- the configuration file used should be set to production.properties
- the profile to be used must be set to "production" so the default
(debug mode based) profile is not
used with the shell bundles in it
So as you can see we need some environment property to be set for both
cases to do the same things. Now is
it possible that the profile can be chosen inside the
config.properties? If so then I do not need a second
property to select the profile.
Alex
Re: Got a problem running felix in production mode
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Marcel Offermans wrote:
> We are using a custom "main" class that bootstraps the framework and installs
> the basic bundles (everything up to and including the "management agent").
> This leaves the system in a state similar to what an initial provisioning
> implementation would do.
>
> We wrap this "main" class in a runnable jar that sets up the classpath to
> include the Felix jars.
The standard Main is overall pretty simplistic, but it does allow you to
specify the location of the config.properties file using a system
property, so it is always possible to have a production
config.properties file too that you select via a system property when
you run in production mode.
-> richard
Re: Got a problem running felix in production mode
Posted by Marcel Offermans <ma...@xs4all.nl>.
On Saturday 11 March 2006 21:45, Richard S. Hall wrote:
> Alex Karasulu wrote:
> > As you can see it's stuff infinitely printing out to the console
> > waiting for IO but well there is
> > no console since the file descriptor does not exist for stdin. I
> > think the best way to do this
> > is to enable a switch that let's use select a different
> > config.properties file.
> Yes, you need a different config.properties...or at least a different
> felix.auto.start property inside of config.properties. Proposals on how
> to do this are welcome.
We are using a custom "main" class that bootstraps the framework and installs
the basic bundles (everything up to and including the "management agent").
This leaves the system in a state similar to what an initial provisioning
implementation would do.
We wrap this "main" class in a runnable jar that sets up the classpath to
include the Felix jars.
Greetings, Marcel
Re: Got a problem running felix in production mode
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alex Karasulu wrote:
> As you can see it's stuff infinitely printing out to the console
> waiting for IO but well there is
> no console since the file descriptor does not exist for stdin. I
> think the best way to do this
> is to enable a switch that let's use select a different
> config.properties file.
Yes, you need a different config.properties...or at least a different
felix.auto.start property inside of config.properties. Proposals on how
to do this are welcome.
-> richard
Re: Got a problem running felix in production mode
Posted by Alex Karasulu <ao...@bellsouth.net>.
Alex Karasulu wrote:
> Looks like the standard out log file fills up with ...
>
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> -
> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> -
> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> -
> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> -
> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> ->
>
> It keeps on filling and filling ... it will fill a disk if you let
> it. How can we disable
> this shell in production mode?
Just as a heads up look at the header it prints out first. I can
probably figure out a way
to rig it so this does not load by default but I'm running out of time.
Anyways here's
the head of the log:
DEBUG: WIRE: [1.0] 1.0 -> org.osgi.service.packageadmin -> 0
DEBUG: WIRE: [1.0] 1.0 -> org.osgi.service.startlevel -> 0
DEBUG: WIRE: [1.0] 1.0 -> org.osgi.framework -> 0
DEBUG: WIRE: [1.0] 1.0 -> org.ungoverned.osgi.service.shell -> 1.0
DEBUG: WIRE: [1.0] 1.0 -> org.apache.felix.shell -> 1.0
DEBUG: WIRE: [2.0] 2.0 -> org.osgi.framework -> 0
DEBUG: WIRE: [2.0] 2.0 -> org.apache.felix.shell -> 1.0
-> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> ->
-> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> -
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
-> -> ->
...
As you can see it's stuff infinitely printing out to the console waiting
for IO but well there is
no console since the file descriptor does not exist for stdin. I think
the best way to do this
is to enable a switch that let's use select a different
config.properties file.
Alex
Re: Got a problem running felix in production mode
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Thanks. I will apply this patch.
-> richard
Nektarios K. Papadopoulos wrote:
> ...or ShellTUI can treat problems reading from stdin as fatal and stop
> itself. The attached patch demonstrates what I mean.
>
> --
> nek
>
> Richard S. Hall wrote:
>> Just don't load the ShellTUI bundle, which is responsible for
>> printing "-> " on its own thread. In production mode you don't need
>> this bundle at all. You can still install the shell bundle, but
>> install it with telnetd or something similar so you can have remote
>> shell access. ShellTUI is only for interactive console execution of
>> the framework.
>>
>> -> richard
>>
>> Alex Karasulu wrote:
>>
>>> Looks like the standard out log file fills up with ...
>>>
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> -
>>> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> -
>>> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> -
>>> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> -
>>> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>>
>>> It keeps on filling and filling ... it will fill a disk if you let
>>> it. How can we disable
>>> this shell in production mode?
>>>
>>> Alex
>>>
>>>
>>
>
> ------------------------------------------------------------------------
>
> Index: org.apache.felix.shell.tui/src/main/java/org/apache/felix/shell/tui/Activator.java
> ===================================================================
> --- org.apache.felix.shell.tui/src/main/java/org/apache/felix/shell/tui/Activator.java (revision 384538)
> +++ org.apache.felix.shell.tui/src/main/java/org/apache/felix/shell/tui/Activator.java (working copy)
> @@ -25,6 +25,7 @@
> {
> private transient BundleContext m_context = null;
> private transient ShellTuiRunnable m_runnable = null;
> + private transient Thread m_thread = null;
> private transient ServiceReference m_shellRef = null;
> private transient ShellService m_shell = null;
>
> @@ -78,9 +79,11 @@
> initializeService();
>
> // Start impl thread.
> - new Thread(
> + m_thread = new Thread(
> m_runnable = new ShellTuiRunnable(),
> - "Felix Shell TUI").start();
> + "Felix Shell TUI");
> + m_thread.setDaemon(true);
> + m_thread.start();
> }
>
> private synchronized void initializeService()
> @@ -121,6 +124,14 @@
> System.out.print("-> ");
>
> try {
> + while (!in.ready()) {
> + synchronized(in) {
> + try {
> + in.wait(100);
> + } catch(InterruptedException ie) {
> + }
> + }
> + }
> line = in.readLine();
> } catch (IOException ex) {
> System.err.println("Could not read input, please try again.");
> @@ -132,11 +143,21 @@
> if (m_shell == null)
> {
> System.out.println("No impl service available.");
> + try {
> + m_context.getBundle().stop();
> + } catch (BundleException bce) {
> + stop =true;
> + }
> continue;
> }
>
> if (line == null)
> {
> + try {
> + m_context.getBundle().stop();
> + } catch (BundleException bce) {
> + stop =true;
> + }
> continue;
> }
>
>
Re: Got a problem running felix in production mode
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alex Karasulu wrote:
> Richard S. Hall wrote:
>> Yes, you could just detect whether stdin is invalid first, but you
>> would need a thread if stdin is valid. Is there a proper way to
>> determine if stdin is valid?
>
> Hmmm this behavoir is truly unexpected since jsvc does some strange
> things to daemonize the process. I don't really know how this would
> manifest itself in the Java space. Basically the stdin file
> descriptor is closed in which case the String line will return null
> all the time (just a suspicion from looking at the code and the
> observed behavoir). I think rigging in the ability to switch the
> profile and the configuration file when not in debug mode is the key.
Sounds fine by me. For now, we will ignore modifying Shell TUI for
detecting an invalid stdin, but I will modify Shell TUI so that it
interrupts its thread when stop() is called.
-> richard
Re: Got a problem running felix in production mode
Posted by Alex Karasulu <ao...@bellsouth.net>.
Richard S. Hall wrote:
> Alex Karasulu wrote:
>> Richard S. Hall wrote:
>>> After looking closer at the patch I notice a couple of issues:
>>>
>>> 1. Does it make sense to set the thread as a daemon? I don't think
>>> frameworks are required to have non-daemon threads...we would have
>>> to think about it.
>> Personally I don't understand why there is another thread? What's
>> the point to it? Can't you just detect that stdin is not valid and
>> just handle things in the same thread?
>
> Yes, you could just detect whether stdin is invalid first, but you
> would need a thread if stdin is valid. Is there a proper way to
> determine if stdin is valid?
Hmmm this behavoir is truly unexpected since jsvc does some strange
things to daemonize the process. I don't really know how this would
manifest itself in the Java space. Basically the stdin file descriptor
is closed in which case the String line will return null all the time
(just a suspicion from looking at the code and the observed behavoir).
I think rigging in the ability to switch the profile and the
configuration file when not in debug mode is the key.
Alex
Re: Got a problem running felix in production mode
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alex Karasulu wrote:
> Richard S. Hall wrote:
>> After looking closer at the patch I notice a couple of issues:
>>
>> 1. Does it make sense to set the thread as a daemon? I don't think
>> frameworks are required to have non-daemon threads...we would have
>> to think about it.
> Personally I don't understand why there is another thread? What's the
> point to it? Can't you just detect that stdin is not valid and just
> handle things in the same thread?
Yes, you could just detect whether stdin is invalid first, but you would
need a thread if stdin is valid. Is there a proper way to determine if
stdin is valid?
-> richard
Re: Got a problem running felix in production mode
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Nektarios K. Papadopoulos wrote:
> Alex Karasulu wrote:
>> Personally I don't understand why there is another thread? What's
>> the point to it? Can't you just detect that stdin is not valid and
>> just handle things in the same thread?
> I think there is just one thread.
I assumed Alex meant to check for an invalid stdin before even starting
the TUI thread.
> Anyway, I initially wrote this patch (sometime ago) when testing
> ShellTUI against Oscar 1.0.2, in situations where I wanted Oscar to
> *NOT* run interactivelly. IIRC, the daemon flag is required if:
> - the framework is started in the background
> - the framework is shutdown not from ShellTUI (e.g. telnet)
This may be the case, but currently I am not sure why it would be. If
you shut the framework down, it doesn't really matter what threads are
active, because all bundles will get stopped and should exit.
We need to investigate the threads being started by the framework and
see which ones are daemon or not and determine what they should be.
There are three threads: event dispatcher (non-daemon), package admin
(daemon), and start level (daemon).
I think my reasoning for making the event dispatcher non-daemon is so
that it wouldn't be interrupted in the middle of delivering events, but
this is probably a non-issue since the framework would be shutting down
anyway.
So, it might be possible to make them all daemon threads. The question
to answer is who should be responsible for keeping the VM from exiting,
the framework itself or the framework launcher?
> Then the ShellTUI thread is stuck in the in.readLine() call and the
> framework never ends. I'm not sure if this applies to felix.
Yes, that makes sense...perhaps the simple solution here is to interrupt
the thread from the stop() method.
One thing that might be helpful is if we make all threads daemons, then
it would eliminate one source of confusion for people when they start
the framework and it cannot find the shell bundles. In that scenario it
appears that the framework is hung, but in reality it is just running in
the background without an interactive shell.
Do people have an opinion on what is the best approach?
>>> 2. Bundles are not supposed to call stop on themselves, so we would
>>> have to change that...we don't really need to stop the bundle, we
>>> can just have it stop processing input.
>>
>> +1 to this ... that's the core problem.
>>
> I'm sure I saw this on other bunldes, so please explain: how should a
> bundle stop itself if required ?
It should need to, in theory, it should just go into some
non-functioning or degraded mode; this is the job of the management agent.
I should point out, though, that Felix doesn't check for this, so it is
possible to do.
-> richard
Re: Got a problem running felix in production mode
Posted by "Nektarios K. Papadopoulos" <np...@inaccessnetworks.com>.
Alex Karasulu wrote:
> Richard S. Hall wrote:
>
>> After looking closer at the patch I notice a couple of issues:
>>
>> 1. Does it make sense to set the thread as a daemon? I don't think
>> frameworks are required to have non-daemon threads...we would have
>> to think about it.
>
> Personally I don't understand why there is another thread? What's the
> point to it? Can't you just detect that stdin is not valid and just
> handle things in the same thread?
I think there is just one thread.
Anyway, I initially wrote this patch (sometime ago) when testing
ShellTUI against Oscar 1.0.2, in situations where I wanted Oscar to
*NOT* run interactivelly. IIRC, the daemon flag is required if:
- the framework is started in the background
- the framework is shutdown not from ShellTUI (e.g. telnet)
Then the ShellTUI thread is stuck in the in.readLine() call and the
framework never ends. I'm not sure if this applies to felix.
>
>> 2. Bundles are not supposed to call stop on themselves, so we would
>> have to change that...we don't really need to stop the bundle, we
>> can just have it stop processing input.
>
> +1 to this ... that's the core problem.
>
I'm sure I saw this on other bunldes, so please explain: how should a
bundle stop itself if required ?
Nevertheless,
+1
> Alex
>
--
nek
Re: Got a problem running felix in production mode
Posted by Alex Karasulu <ao...@bellsouth.net>.
Richard S. Hall wrote:
> After looking closer at the patch I notice a couple of issues:
>
> 1. Does it make sense to set the thread as a daemon? I don't think
> frameworks are required to have non-daemon threads...we would have
> to think about it.
Personally I don't understand why there is another thread? What's the
point to it? Can't you just detect that stdin is not valid and just
handle things in the same thread?
> 2. Bundles are not supposed to call stop on themselves, so we would
> have to change that...we don't really need to stop the bundle, we
> can just have it stop processing input.
+1 to this ... that's the core problem.
Alex
Re: Got a problem running felix in production mode
Posted by "Richard S. Hall" <he...@ungoverned.org>.
After looking closer at the patch I notice a couple of issues:
1. Does it make sense to set the thread as a daemon? I don't think
frameworks are required to have non-daemon threads...we would have
to think about it.
2. Bundles are not supposed to call stop on themselves, so we would
have to change that...we don't really need to stop the bundle, we
can just have it stop processing input.
Thoughts?
-> richard
Nektarios K. Papadopoulos wrote:
> ...or ShellTUI can treat problems reading from stdin as fatal and stop
> itself. The attached patch demonstrates what I mean.
>
> --
> nek
>
> Richard S. Hall wrote:
>> Just don't load the ShellTUI bundle, which is responsible for
>> printing "-> " on its own thread. In production mode you don't need
>> this bundle at all. You can still install the shell bundle, but
>> install it with telnetd or something similar so you can have remote
>> shell access. ShellTUI is only for interactive console execution of
>> the framework.
>>
>> -> richard
>>
>> Alex Karasulu wrote:
>>
>>> Looks like the standard out log file fills up with ...
>>>
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> -
>>> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> -
>>> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> -
>>> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> -
>>> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>>> -> -> -> ->
>>>
>>> It keeps on filling and filling ... it will fill a disk if you let
>>> it. How can we disable
>>> this shell in production mode?
>>>
>>> Alex
>>>
>>>
>>
>
> ------------------------------------------------------------------------
>
> Index: org.apache.felix.shell.tui/src/main/java/org/apache/felix/shell/tui/Activator.java
> ===================================================================
> --- org.apache.felix.shell.tui/src/main/java/org/apache/felix/shell/tui/Activator.java (revision 384538)
> +++ org.apache.felix.shell.tui/src/main/java/org/apache/felix/shell/tui/Activator.java (working copy)
> @@ -25,6 +25,7 @@
> {
> private transient BundleContext m_context = null;
> private transient ShellTuiRunnable m_runnable = null;
> + private transient Thread m_thread = null;
> private transient ServiceReference m_shellRef = null;
> private transient ShellService m_shell = null;
>
> @@ -78,9 +79,11 @@
> initializeService();
>
> // Start impl thread.
> - new Thread(
> + m_thread = new Thread(
> m_runnable = new ShellTuiRunnable(),
> - "Felix Shell TUI").start();
> + "Felix Shell TUI");
> + m_thread.setDaemon(true);
> + m_thread.start();
> }
>
> private synchronized void initializeService()
> @@ -121,6 +124,14 @@
> System.out.print("-> ");
>
> try {
> + while (!in.ready()) {
> + synchronized(in) {
> + try {
> + in.wait(100);
> + } catch(InterruptedException ie) {
> + }
> + }
> + }
> line = in.readLine();
> } catch (IOException ex) {
> System.err.println("Could not read input, please try again.");
> @@ -132,11 +143,21 @@
> if (m_shell == null)
> {
> System.out.println("No impl service available.");
> + try {
> + m_context.getBundle().stop();
> + } catch (BundleException bce) {
> + stop =true;
> + }
> continue;
> }
>
> if (line == null)
> {
> + try {
> + m_context.getBundle().stop();
> + } catch (BundleException bce) {
> + stop =true;
> + }
> continue;
> }
>
>
Re: Got a problem running felix in production mode
Posted by "Nektarios K. Papadopoulos" <np...@inaccessnetworks.com>.
...or ShellTUI can treat problems reading from stdin as fatal and stop
itself. The attached patch demonstrates what I mean.
--
nek
Richard S. Hall wrote:
> Just don't load the ShellTUI bundle, which is responsible for printing
> "-> " on its own thread. In production mode you don't need this bundle
> at all. You can still install the shell bundle, but install it with
> telnetd or something similar so you can have remote shell access.
> ShellTUI is only for interactive console execution of the framework.
>
> -> richard
>
> Alex Karasulu wrote:
>
>> Looks like the standard out log file fills up with ...
>>
>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>> -> -> -> ->
>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>> -> -> -> -
>> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>> -> -> ->
>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>> -> -> -> ->
>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>> -> -> -> -
>> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>> -> -> ->
>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>> -> -> -> ->
>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>> -> -> -> -
>> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>> -> -> ->
>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>> -> -> -> ->
>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>> -> -> -> -
>> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>> -> -> ->
>> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
>> -> -> -> ->
>>
>> It keeps on filling and filling ... it will fill a disk if you let
>> it. How can we disable
>> this shell in production mode?
>>
>> Alex
>>
>>
>
--
______________________________________________________________
Nektarios K. Papadopoulos
Senior Engineer
Software Engineering Group
inAccess Networks
95A Pentelis Avenue. Tel : +30-210-6837640
152 34 Halandri Athens Fax : +30-210-6899504
______________________________________________________________
Re: Got a problem running felix in production mode
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Just don't load the ShellTUI bundle, which is responsible for printing
"-> " on its own thread. In production mode you don't need this bundle
at all. You can still install the shell bundle, but install it with
telnetd or something similar so you can have remote shell access.
ShellTUI is only for interactive console execution of the framework.
-> richard
Alex Karasulu wrote:
> Looks like the standard out log file fills up with ...
>
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> -
> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> -
> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> -
> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> -
> > -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> ->
> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> ->
> -> -> -> ->
>
> It keeps on filling and filling ... it will fill a disk if you let
> it. How can we disable
> this shell in production mode?
>
> Alex
>
>