You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Mike Hummel <mh...@mhus.de> on 2020/03/04 08:14:12 UTC
Karaf Commands and Cltr-C
Hello,
I try to break my karaf commands with Ctrl-C (e.g. by using Thread.sleep()). In older releases this was no problem, but since the shell starts every command in a separate thread the Cltr-C is also caught by gogo and it will unlock the command from the console.
I also tried this
session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
but it gets not the effect.
Is there a way to recognise if the current command is separated from the current gogo command line?
A sample snipped:
Object oldIgnoreInterrupts = session.get(Session.IGNORE_INTERRUPTS);
try {
session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
return doExecute(this, cmd, parameters);
} finally {
session.put(Session.IGNORE_INTERRUPTS, oldIgnoreInterrupts);
}
public Object doExecute(CmdShitYo base, String cmd, String[] parameters) throws Exception {
if (cmd.equals("ctrl-c")) {
try {
while (true) {
System.out.println("Wait for Ctrl-C - off");
MThread.sleep(3000);
}
} catch (InterruptedException e) {
System.out.println("Interrupted !!!!");
}
}
}
MThread:
public static void sleep(long _millisec) {
try {
Thread.sleep(_millisec);
} catch (InterruptedException e) {
log.i(e);
}
}
This will output
Wait for Ctrl-C - off
Wait for Ctrl-C - on
Wait for Ctrl-C - off
Wait for Ctrl-C - on
...
If I interrupt, it will be separated from gogo shell and iterate for ever. - And I see the interrupted exception in the log.
Thx,
Mike
Re: Karaf Commands and Cltr-C
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Agree, that’s another topic. But again, it’s surprising as log:tail works same way.
I will try to reproduce with Karaf 4.2.8. I think it could be related to jline.
Regards
JB
> Le 15 mars 2020 à 09:04, Mike Hummel <mh...@mhus.de> a écrit :
>
> Not a problem in karaf. But it looks like IGNORE_INTERRUPS is useless.
>
>
> For interests I tried a few scenarios to inspect the behavior
>
> The following scenario will fail with full lost of cmd output of each following command:
>
> System.out.println("5: Wait for Ctrl-C - generateRsaKey and MThread.sleepInLoop");
> long start = System.currentTimeMillis();
> while (!MPeriod.isTimeOut(start, sleep)) {
> MBouncy.generateRsaKey(MBouncy.RSA_KEY_SIZE.B2048);
> }
> System.out.println("Finish loop");
> if (Thread.interrupted())
> throw new InterruptedException();
> Thread.sleep(100);
>
>
> It throws an exception after "Finish loop" but it looks like there is no output anymore:
>
>
> karaf@reactive()> shityo stress ctrl-c scenario=5
> --- Thread ID 63
> >>> Loop 3
> 5: Wait for Ctrl-C - generateRsaKey and MThread.sleepInLoop
> Finish loop
> >>> Loop 2
> 5: Wait for Ctrl-C - generateRsaKey and MThread.sleepInLoop
> Finish loop
> >>> Loop 1
> 5: Wait for Ctrl-C - generateRsaKey and MThread.sleepInLoop
> ^C~ karaf@reactive()> Finish loop
> karaf@reactive()> list
> karaf@reactive()>
>
> Even for each command!
>
> In the debugger I see that the exception is throw and thats the end of output to the console from a command.
>
> You can see the full code here: https://github.com/mhus/mhus-osgi-tools/blob/master/karaf-commands/src/main/java/de/mhus/karaf/commands/testit/StressShit.java <https://github.com/mhus/mhus-osgi-tools/blob/master/karaf-commands/src/main/java/de/mhus/karaf/commands/testit/StressShit.java> line 87
>
> But it looks like this is another topic. But is it karaf or felix?
>
>
>
>> On 15. Mar 2020, at 06:03, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>
>> Hi Mike,
>>
>> Yes, IMHO there’s no problem on Karaf (sorry for the delay in my answer, the situation is "complicated" here ;) ): it just does the interrupt correctly.
>>
>> It mainly depends how you deal with interrupt in your piece of code.
>>
>> I’m happy it works now.
>>
>> Regards
>> JB
>>
>>> Le 15 mars 2020 à 00:22, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>
>>> Hello Guillaume,
>>>
>>> thank you for the hint. I already tried Thread.interrupted() but found my problem in flag clearing if another wait() is called.
>>>
>>> To be sure to interrupt a loop I have to check Thread.interrupted() before each Thread.sleep() in the loop. Like this
>>>
>>> public static void sleepInLoop(long _millisec) throws InterruptedException {
>>> if (Thread.interrupted())
>>> throw new InterruptedException();
>>> Thread.sleep(_millisec);
>>> }
>>>
>>> And this will solfe the problem!
>>>
>>> Thx,
>>>
>>> Mike
>>>
>>>
>>>
>>>> On 14. Mar 2020, at 21:51, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>>>
>>>> The Ctrl+C default behavior in Karaf is to to call Thread.interrupt().
>>>> The effect depends on what the thread is doing, you'll find more information at [1].
>>>> If you want the command to be interrupted, the code needs to support it correctly.
>>>>
>>>> [1] https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html <https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html>
>>>>
>>>> Cheers,
>>>> Guillaume Nodet
>>>>
>>>>
>>>> Le sam. 14 mars 2020 à 20:45, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>> The problem is if I not listen to ctrl-c in the moment of the interrupt
>>>>
>>>> while(true) {
>>>> 1) do something
>>>> 2) Thread.sleep()
>>>> }
>>>>
>>>> And the 'Interrupt' is while (1) and not in (2) then the cmd will not be interrupted. - I tested it.
>>>>
>>>> (The interrupt will be thrown in Thread.sleep() and (I think) in Object.wait(), but not in 'normal' executon or if try {} (catch Throwable) is used)
>>>>
>>>> It will not break the command loop but will move the command in background (correct: status == Done) and the cmd will not stop working.
>>>>
>>>> something like this would be nice
>>>>
>>>> while(true) {
>>>> 1) something
>>>> 2) Thread.sleep()
>>>> 3) if (is canceled) break;
>>>> }
>>>>
>>>> But (in 3) for the command it's not possible to check the status of execution. It's in org.apache.felix.gogo.runtime.CommandSessionImpl
>>>>
>>>> So using crtl-c to cancel the command execution is like roulette.
>>>>
>>>>
>>>>
>>>>> On 14. Mar 2020, at 20:28, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>>>>
>>>>> CTRL-C just works fine in Karaf commands (including the one creating thread like log:tail).
>>>>>
>>>>> So, your use case is about intercepting CTRL-C yourself, right ? What’s the use case you want to achieve ?
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>> Le 14 mars 2020 à 18:26, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>>>
>>>>>> Looks like it's not possible to block the ctrl-c event. It's implemented in felix gogo shell ans since every cmd (in a pipe) is executed in a separate thread it's not clear witch one should do the interruption control
>>>>>>
>>>>>> Maybe the feature "IGNORE_INTERRUPS" should not be offered.
>>>>>>
>>>>>> But felix should inform the commands if the execution is canceled. For example by checking for the Closeable interface and calling the close() method.
>>>>>>
>>>>>>
>>>>>>> On 14. Mar 2020, at 11:09, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>>>>>>
>>>>>>> Hi Mike,
>>>>>>>
>>>>>>> Let me take a look.
>>>>>>>
>>>>>>> Thanks for the report.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>> Le 14 mars 2020 à 09:03, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I did a little bit research for IGNORE_INTERRUPTS in the karaf sources. I found in master and karaf-4.2.x the same results.
>>>>>>>>
>>>>>>>> The const is defined in 'Sessio'n and 'SessionProperties', but only used from 'Session'.
>>>>>>>>
>>>>>>>> It is only used to enable the behaviour but never used to implement some kind of behaviour.
>>>>>>>>
>>>>>>>> Is there someone how can can prove this? And what is the background for two definitions of the same const? If I have the background I could look for a fix.
>>>>>>>>
>>>>>>>> Just now I created KARAF-6645 to track the problem.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 5. Mar 2020, at 09:53, Mike Hummel <mh@mhus.de <ma...@mhus.de>> wrote:
>>>>>>>>>
>>>>>>>>> It's not easy to say ... In 4.2.3 it's broken and in 4.1.x it was ok.
>>>>>>>>>
>>>>>>>>> I testet the flag IGNORE_INTERRUPTS in 4.2.7 and it was not working as I imagine. I'm even not sure if the flag is exact what I want to do.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 4. Mar 2020, at 09:18, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>>>>>>>>>
>>>>>>>>>> Could you be more specific about "older releases" ? Do you know in which release it broke ?
>>>>>>>>>>
>>>>>>>>>> Le mer. 4 mars 2020 à 09:14, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I try to break my karaf commands with Ctrl-C (e.g. by using Thread.sleep()). In older releases this was no problem, but since the shell starts every command in a separate thread the Cltr-C is also caught by gogo and it will unlock the command from the console.
>>>>>>>>>>
>>>>>>>>>> I also tried this
>>>>>>>>>>
>>>>>>>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>>>>>>>>
>>>>>>>>>> but it gets not the effect.
>>>>>>>>>>
>>>>>>>>>> Is there a way to recognise if the current command is separated from the current gogo command line?
>>>>>>>>>>
>>>>>>>>>> A sample snipped:
>>>>>>>>>>
>>>>>>>>>> Object oldIgnoreInterrupts = session.get(Session.IGNORE_INTERRUPTS);
>>>>>>>>>> try {
>>>>>>>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>>>>>>>> return doExecute(this, cmd, parameters);
>>>>>>>>>> } finally {
>>>>>>>>>> session.put(Session.IGNORE_INTERRUPTS, oldIgnoreInterrupts);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> public Object doExecute(CmdShitYo base, String cmd, String[] parameters) throws Exception {
>>>>>>>>>> if (cmd.equals("ctrl-c")) {
>>>>>>>>>> try {
>>>>>>>>>> while (true) {
>>>>>>>>>> System.out.println("Wait for Ctrl-C - off");
>>>>>>>>>> MThread.sleep(3000);
>>>>>>>>>> }
>>>>>>>>>> } catch (InterruptedException e) {
>>>>>>>>>> System.out.println("Interrupted !!!!");
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> MThread:
>>>>>>>>>> public static void sleep(long _millisec) {
>>>>>>>>>> try {
>>>>>>>>>> Thread.sleep(_millisec);
>>>>>>>>>> } catch (InterruptedException e) {
>>>>>>>>>> log.i(e);
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> This will output
>>>>>>>>>>
>>>>>>>>>> Wait for Ctrl-C - off
>>>>>>>>>> Wait for Ctrl-C - on
>>>>>>>>>> Wait for Ctrl-C - off
>>>>>>>>>> Wait for Ctrl-C - on
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>> If I interrupt, it will be separated from gogo shell and iterate for ever. - And I see the interrupted exception in the log.
>>>>>>>>>>
>>>>>>>>>> Thx,
>>>>>>>>>>
>>>>>>>>>> Mike
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> ------------------------
>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>>
>>>
>>
>
Re: Karaf Commands and Cltr-C
Posted by Mike Hummel <mh...@mhus.de>.
Not a problem in karaf. But it looks like IGNORE_INTERRUPS is useless.
For interests I tried a few scenarios to inspect the behavior
The following scenario will fail with full lost of cmd output of each following command:
System.out.println("5: Wait for Ctrl-C - generateRsaKey and MThread.sleepInLoop");
long start = System.currentTimeMillis();
while (!MPeriod.isTimeOut(start, sleep)) {
MBouncy.generateRsaKey(MBouncy.RSA_KEY_SIZE.B2048);
}
System.out.println("Finish loop");
if (Thread.interrupted())
throw new InterruptedException();
Thread.sleep(100);
It throws an exception after "Finish loop" but it looks like there is no output anymore:
karaf@reactive()> shityo stress ctrl-c scenario=5
--- Thread ID 63
>>> Loop 3
5: Wait for Ctrl-C - generateRsaKey and MThread.sleepInLoop
Finish loop
>>> Loop 2
5: Wait for Ctrl-C - generateRsaKey and MThread.sleepInLoop
Finish loop
>>> Loop 1
5: Wait for Ctrl-C - generateRsaKey and MThread.sleepInLoop
^C~ karaf@reactive()> Finish loop
karaf@reactive()> list
karaf@reactive()>
Even for each command!
In the debugger I see that the exception is throw and thats the end of output to the console from a command.
You can see the full code here: https://github.com/mhus/mhus-osgi-tools/blob/master/karaf-commands/src/main/java/de/mhus/karaf/commands/testit/StressShit.java <https://github.com/mhus/mhus-osgi-tools/blob/master/karaf-commands/src/main/java/de/mhus/karaf/commands/testit/StressShit.java> line 87
But it looks like this is another topic. But is it karaf or felix?
> On 15. Mar 2020, at 06:03, Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>
> Hi Mike,
>
> Yes, IMHO there’s no problem on Karaf (sorry for the delay in my answer, the situation is "complicated" here ;) ): it just does the interrupt correctly.
>
> It mainly depends how you deal with interrupt in your piece of code.
>
> I’m happy it works now.
>
> Regards
> JB
>
>> Le 15 mars 2020 à 00:22, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>
>> Hello Guillaume,
>>
>> thank you for the hint. I already tried Thread.interrupted() but found my problem in flag clearing if another wait() is called.
>>
>> To be sure to interrupt a loop I have to check Thread.interrupted() before each Thread.sleep() in the loop. Like this
>>
>> public static void sleepInLoop(long _millisec) throws InterruptedException {
>> if (Thread.interrupted())
>> throw new InterruptedException();
>> Thread.sleep(_millisec);
>> }
>>
>> And this will solfe the problem!
>>
>> Thx,
>>
>> Mike
>>
>>
>>
>>> On 14. Mar 2020, at 21:51, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>>
>>> The Ctrl+C default behavior in Karaf is to to call Thread.interrupt().
>>> The effect depends on what the thread is doing, you'll find more information at [1].
>>> If you want the command to be interrupted, the code needs to support it correctly.
>>>
>>> [1] https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html <https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html>
>>>
>>> Cheers,
>>> Guillaume Nodet
>>>
>>>
>>> Le sam. 14 mars 2020 à 20:45, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>> The problem is if I not listen to ctrl-c in the moment of the interrupt
>>>
>>> while(true) {
>>> 1) do something
>>> 2) Thread.sleep()
>>> }
>>>
>>> And the 'Interrupt' is while (1) and not in (2) then the cmd will not be interrupted. - I tested it.
>>>
>>> (The interrupt will be thrown in Thread.sleep() and (I think) in Object.wait(), but not in 'normal' executon or if try {} (catch Throwable) is used)
>>>
>>> It will not break the command loop but will move the command in background (correct: status == Done) and the cmd will not stop working.
>>>
>>> something like this would be nice
>>>
>>> while(true) {
>>> 1) something
>>> 2) Thread.sleep()
>>> 3) if (is canceled) break;
>>> }
>>>
>>> But (in 3) for the command it's not possible to check the status of execution. It's in org.apache.felix.gogo.runtime.CommandSessionImpl
>>>
>>> So using crtl-c to cancel the command execution is like roulette.
>>>
>>>
>>>
>>>> On 14. Mar 2020, at 20:28, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>>>
>>>> CTRL-C just works fine in Karaf commands (including the one creating thread like log:tail).
>>>>
>>>> So, your use case is about intercepting CTRL-C yourself, right ? What’s the use case you want to achieve ?
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>> Le 14 mars 2020 à 18:26, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>>
>>>>> Looks like it's not possible to block the ctrl-c event. It's implemented in felix gogo shell ans since every cmd (in a pipe) is executed in a separate thread it's not clear witch one should do the interruption control
>>>>>
>>>>> Maybe the feature "IGNORE_INTERRUPS" should not be offered.
>>>>>
>>>>> But felix should inform the commands if the execution is canceled. For example by checking for the Closeable interface and calling the close() method.
>>>>>
>>>>>
>>>>>> On 14. Mar 2020, at 11:09, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>>>>>
>>>>>> Hi Mike,
>>>>>>
>>>>>> Let me take a look.
>>>>>>
>>>>>> Thanks for the report.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>> Le 14 mars 2020 à 09:03, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I did a little bit research for IGNORE_INTERRUPTS in the karaf sources. I found in master and karaf-4.2.x the same results.
>>>>>>>
>>>>>>> The const is defined in 'Sessio'n and 'SessionProperties', but only used from 'Session'.
>>>>>>>
>>>>>>> It is only used to enable the behaviour but never used to implement some kind of behaviour.
>>>>>>>
>>>>>>> Is there someone how can can prove this? And what is the background for two definitions of the same const? If I have the background I could look for a fix.
>>>>>>>
>>>>>>> Just now I created KARAF-6645 to track the problem.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 5. Mar 2020, at 09:53, Mike Hummel <mh@mhus.de <ma...@mhus.de>> wrote:
>>>>>>>>
>>>>>>>> It's not easy to say ... In 4.2.3 it's broken and in 4.1.x it was ok.
>>>>>>>>
>>>>>>>> I testet the flag IGNORE_INTERRUPTS in 4.2.7 and it was not working as I imagine. I'm even not sure if the flag is exact what I want to do.
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 4. Mar 2020, at 09:18, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>>>>>>>>
>>>>>>>>> Could you be more specific about "older releases" ? Do you know in which release it broke ?
>>>>>>>>>
>>>>>>>>> Le mer. 4 mars 2020 à 09:14, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I try to break my karaf commands with Ctrl-C (e.g. by using Thread.sleep()). In older releases this was no problem, but since the shell starts every command in a separate thread the Cltr-C is also caught by gogo and it will unlock the command from the console.
>>>>>>>>>
>>>>>>>>> I also tried this
>>>>>>>>>
>>>>>>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>>>>>>>
>>>>>>>>> but it gets not the effect.
>>>>>>>>>
>>>>>>>>> Is there a way to recognise if the current command is separated from the current gogo command line?
>>>>>>>>>
>>>>>>>>> A sample snipped:
>>>>>>>>>
>>>>>>>>> Object oldIgnoreInterrupts = session.get(Session.IGNORE_INTERRUPTS);
>>>>>>>>> try {
>>>>>>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>>>>>>> return doExecute(this, cmd, parameters);
>>>>>>>>> } finally {
>>>>>>>>> session.put(Session.IGNORE_INTERRUPTS, oldIgnoreInterrupts);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> public Object doExecute(CmdShitYo base, String cmd, String[] parameters) throws Exception {
>>>>>>>>> if (cmd.equals("ctrl-c")) {
>>>>>>>>> try {
>>>>>>>>> while (true) {
>>>>>>>>> System.out.println("Wait for Ctrl-C - off");
>>>>>>>>> MThread.sleep(3000);
>>>>>>>>> }
>>>>>>>>> } catch (InterruptedException e) {
>>>>>>>>> System.out.println("Interrupted !!!!");
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> MThread:
>>>>>>>>> public static void sleep(long _millisec) {
>>>>>>>>> try {
>>>>>>>>> Thread.sleep(_millisec);
>>>>>>>>> } catch (InterruptedException e) {
>>>>>>>>> log.i(e);
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> This will output
>>>>>>>>>
>>>>>>>>> Wait for Ctrl-C - off
>>>>>>>>> Wait for Ctrl-C - on
>>>>>>>>> Wait for Ctrl-C - off
>>>>>>>>> Wait for Ctrl-C - on
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> If I interrupt, it will be separated from gogo shell and iterate for ever. - And I see the interrupted exception in the log.
>>>>>>>>>
>>>>>>>>> Thx,
>>>>>>>>>
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> ------------------------
>>>>>>>>> Guillaume Nodet
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>>
>>
>
Re: Karaf Commands and Cltr-C
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi Mike,
Yes, IMHO there’s no problem on Karaf (sorry for the delay in my answer, the situation is "complicated" here ;) ): it just does the interrupt correctly.
It mainly depends how you deal with interrupt in your piece of code.
I’m happy it works now.
Regards
JB
> Le 15 mars 2020 à 00:22, Mike Hummel <mh...@mhus.de> a écrit :
>
> Hello Guillaume,
>
> thank you for the hint. I already tried Thread.interrupted() but found my problem in flag clearing if another wait() is called.
>
> To be sure to interrupt a loop I have to check Thread.interrupted() before each Thread.sleep() in the loop. Like this
>
> public static void sleepInLoop(long _millisec) throws InterruptedException {
> if (Thread.interrupted())
> throw new InterruptedException();
> Thread.sleep(_millisec);
> }
>
> And this will solfe the problem!
>
> Thx,
>
> Mike
>
>
>
>> On 14. Mar 2020, at 21:51, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>
>> The Ctrl+C default behavior in Karaf is to to call Thread.interrupt().
>> The effect depends on what the thread is doing, you'll find more information at [1].
>> If you want the command to be interrupted, the code needs to support it correctly.
>>
>> [1] https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html <https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html>
>>
>> Cheers,
>> Guillaume Nodet
>>
>>
>> Le sam. 14 mars 2020 à 20:45, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>> The problem is if I not listen to ctrl-c in the moment of the interrupt
>>
>> while(true) {
>> 1) do something
>> 2) Thread.sleep()
>> }
>>
>> And the 'Interrupt' is while (1) and not in (2) then the cmd will not be interrupted. - I tested it.
>>
>> (The interrupt will be thrown in Thread.sleep() and (I think) in Object.wait(), but not in 'normal' executon or if try {} (catch Throwable) is used)
>>
>> It will not break the command loop but will move the command in background (correct: status == Done) and the cmd will not stop working.
>>
>> something like this would be nice
>>
>> while(true) {
>> 1) something
>> 2) Thread.sleep()
>> 3) if (is canceled) break;
>> }
>>
>> But (in 3) for the command it's not possible to check the status of execution. It's in org.apache.felix.gogo.runtime.CommandSessionImpl
>>
>> So using crtl-c to cancel the command execution is like roulette.
>>
>>
>>
>>> On 14. Mar 2020, at 20:28, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>>
>>> CTRL-C just works fine in Karaf commands (including the one creating thread like log:tail).
>>>
>>> So, your use case is about intercepting CTRL-C yourself, right ? What’s the use case you want to achieve ?
>>>
>>> Regards
>>> JB
>>>
>>>> Le 14 mars 2020 à 18:26, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>
>>>> Looks like it's not possible to block the ctrl-c event. It's implemented in felix gogo shell ans since every cmd (in a pipe) is executed in a separate thread it's not clear witch one should do the interruption control
>>>>
>>>> Maybe the feature "IGNORE_INTERRUPS" should not be offered.
>>>>
>>>> But felix should inform the commands if the execution is canceled. For example by checking for the Closeable interface and calling the close() method.
>>>>
>>>>
>>>>> On 14. Mar 2020, at 11:09, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>>>>
>>>>> Hi Mike,
>>>>>
>>>>> Let me take a look.
>>>>>
>>>>> Thanks for the report.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>> Le 14 mars 2020 à 09:03, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I did a little bit research for IGNORE_INTERRUPTS in the karaf sources. I found in master and karaf-4.2.x the same results.
>>>>>>
>>>>>> The const is defined in 'Sessio'n and 'SessionProperties', but only used from 'Session'.
>>>>>>
>>>>>> It is only used to enable the behaviour but never used to implement some kind of behaviour.
>>>>>>
>>>>>> Is there someone how can can prove this? And what is the background for two definitions of the same const? If I have the background I could look for a fix.
>>>>>>
>>>>>> Just now I created KARAF-6645 to track the problem.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 5. Mar 2020, at 09:53, Mike Hummel <mh@mhus.de <ma...@mhus.de>> wrote:
>>>>>>>
>>>>>>> It's not easy to say ... In 4.2.3 it's broken and in 4.1.x it was ok.
>>>>>>>
>>>>>>> I testet the flag IGNORE_INTERRUPTS in 4.2.7 and it was not working as I imagine. I'm even not sure if the flag is exact what I want to do.
>>>>>>>
>>>>>>>
>>>>>>>> On 4. Mar 2020, at 09:18, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>>>>>>>
>>>>>>>> Could you be more specific about "older releases" ? Do you know in which release it broke ?
>>>>>>>>
>>>>>>>> Le mer. 4 mars 2020 à 09:14, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I try to break my karaf commands with Ctrl-C (e.g. by using Thread.sleep()). In older releases this was no problem, but since the shell starts every command in a separate thread the Cltr-C is also caught by gogo and it will unlock the command from the console.
>>>>>>>>
>>>>>>>> I also tried this
>>>>>>>>
>>>>>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>>>>>>
>>>>>>>> but it gets not the effect.
>>>>>>>>
>>>>>>>> Is there a way to recognise if the current command is separated from the current gogo command line?
>>>>>>>>
>>>>>>>> A sample snipped:
>>>>>>>>
>>>>>>>> Object oldIgnoreInterrupts = session.get(Session.IGNORE_INTERRUPTS);
>>>>>>>> try {
>>>>>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>>>>>> return doExecute(this, cmd, parameters);
>>>>>>>> } finally {
>>>>>>>> session.put(Session.IGNORE_INTERRUPTS, oldIgnoreInterrupts);
>>>>>>>> }
>>>>>>>>
>>>>>>>> public Object doExecute(CmdShitYo base, String cmd, String[] parameters) throws Exception {
>>>>>>>> if (cmd.equals("ctrl-c")) {
>>>>>>>> try {
>>>>>>>> while (true) {
>>>>>>>> System.out.println("Wait for Ctrl-C - off");
>>>>>>>> MThread.sleep(3000);
>>>>>>>> }
>>>>>>>> } catch (InterruptedException e) {
>>>>>>>> System.out.println("Interrupted !!!!");
>>>>>>>> }
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> MThread:
>>>>>>>> public static void sleep(long _millisec) {
>>>>>>>> try {
>>>>>>>> Thread.sleep(_millisec);
>>>>>>>> } catch (InterruptedException e) {
>>>>>>>> log.i(e);
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> This will output
>>>>>>>>
>>>>>>>> Wait for Ctrl-C - off
>>>>>>>> Wait for Ctrl-C - on
>>>>>>>> Wait for Ctrl-C - off
>>>>>>>> Wait for Ctrl-C - on
>>>>>>>> ...
>>>>>>>>
>>>>>>>> If I interrupt, it will be separated from gogo shell and iterate for ever. - And I see the interrupted exception in the log.
>>>>>>>>
>>>>>>>> Thx,
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ------------------------
>>>>>>>> Guillaume Nodet
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>
Re: Karaf Commands and Cltr-C
Posted by Mike Hummel <mh...@mhus.de>.
Hello Guillaume,
thank you for the hint. I already tried Thread.interrupted() but found my problem in flag clearing if another wait() is called.
To be sure to interrupt a loop I have to check Thread.interrupted() before each Thread.sleep() in the loop. Like this
public static void sleepInLoop(long _millisec) throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
Thread.sleep(_millisec);
}
And this will solfe the problem!
Thx,
Mike
> On 14. Mar 2020, at 21:51, Guillaume Nodet <gn...@apache.org> wrote:
>
> The Ctrl+C default behavior in Karaf is to to call Thread.interrupt().
> The effect depends on what the thread is doing, you'll find more information at [1].
> If you want the command to be interrupted, the code needs to support it correctly.
>
> [1] https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html <https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html>
>
> Cheers,
> Guillaume Nodet
>
>
> Le sam. 14 mars 2020 à 20:45, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
> The problem is if I not listen to ctrl-c in the moment of the interrupt
>
> while(true) {
> 1) do something
> 2) Thread.sleep()
> }
>
> And the 'Interrupt' is while (1) and not in (2) then the cmd will not be interrupted. - I tested it.
>
> (The interrupt will be thrown in Thread.sleep() and (I think) in Object.wait(), but not in 'normal' executon or if try {} (catch Throwable) is used)
>
> It will not break the command loop but will move the command in background (correct: status == Done) and the cmd will not stop working.
>
> something like this would be nice
>
> while(true) {
> 1) something
> 2) Thread.sleep()
> 3) if (is canceled) break;
> }
>
> But (in 3) for the command it's not possible to check the status of execution. It's in org.apache.felix.gogo.runtime.CommandSessionImpl
>
> So using crtl-c to cancel the command execution is like roulette.
>
>
>
>> On 14. Mar 2020, at 20:28, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>
>> CTRL-C just works fine in Karaf commands (including the one creating thread like log:tail).
>>
>> So, your use case is about intercepting CTRL-C yourself, right ? What’s the use case you want to achieve ?
>>
>> Regards
>> JB
>>
>>> Le 14 mars 2020 à 18:26, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>
>>> Looks like it's not possible to block the ctrl-c event. It's implemented in felix gogo shell ans since every cmd (in a pipe) is executed in a separate thread it's not clear witch one should do the interruption control
>>>
>>> Maybe the feature "IGNORE_INTERRUPS" should not be offered.
>>>
>>> But felix should inform the commands if the execution is canceled. For example by checking for the Closeable interface and calling the close() method.
>>>
>>>
>>>> On 14. Mar 2020, at 11:09, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>>>
>>>> Hi Mike,
>>>>
>>>> Let me take a look.
>>>>
>>>> Thanks for the report.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>> Le 14 mars 2020 à 09:03, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>>
>>>>> Hello,
>>>>>
>>>>> I did a little bit research for IGNORE_INTERRUPTS in the karaf sources. I found in master and karaf-4.2.x the same results.
>>>>>
>>>>> The const is defined in 'Sessio'n and 'SessionProperties', but only used from 'Session'.
>>>>>
>>>>> It is only used to enable the behaviour but never used to implement some kind of behaviour.
>>>>>
>>>>> Is there someone how can can prove this? And what is the background for two definitions of the same const? If I have the background I could look for a fix.
>>>>>
>>>>> Just now I created KARAF-6645 to track the problem.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 5. Mar 2020, at 09:53, Mike Hummel <mh@mhus.de <ma...@mhus.de>> wrote:
>>>>>>
>>>>>> It's not easy to say ... In 4.2.3 it's broken and in 4.1.x it was ok.
>>>>>>
>>>>>> I testet the flag IGNORE_INTERRUPTS in 4.2.7 and it was not working as I imagine. I'm even not sure if the flag is exact what I want to do.
>>>>>>
>>>>>>
>>>>>>> On 4. Mar 2020, at 09:18, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>>>>>>
>>>>>>> Could you be more specific about "older releases" ? Do you know in which release it broke ?
>>>>>>>
>>>>>>> Le mer. 4 mars 2020 à 09:14, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>>>> Hello,
>>>>>>>
>>>>>>> I try to break my karaf commands with Ctrl-C (e.g. by using Thread.sleep()). In older releases this was no problem, but since the shell starts every command in a separate thread the Cltr-C is also caught by gogo and it will unlock the command from the console.
>>>>>>>
>>>>>>> I also tried this
>>>>>>>
>>>>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>>>>>
>>>>>>> but it gets not the effect.
>>>>>>>
>>>>>>> Is there a way to recognise if the current command is separated from the current gogo command line?
>>>>>>>
>>>>>>> A sample snipped:
>>>>>>>
>>>>>>> Object oldIgnoreInterrupts = session.get(Session.IGNORE_INTERRUPTS);
>>>>>>> try {
>>>>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>>>>> return doExecute(this, cmd, parameters);
>>>>>>> } finally {
>>>>>>> session.put(Session.IGNORE_INTERRUPTS, oldIgnoreInterrupts);
>>>>>>> }
>>>>>>>
>>>>>>> public Object doExecute(CmdShitYo base, String cmd, String[] parameters) throws Exception {
>>>>>>> if (cmd.equals("ctrl-c")) {
>>>>>>> try {
>>>>>>> while (true) {
>>>>>>> System.out.println("Wait for Ctrl-C - off");
>>>>>>> MThread.sleep(3000);
>>>>>>> }
>>>>>>> } catch (InterruptedException e) {
>>>>>>> System.out.println("Interrupted !!!!");
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> MThread:
>>>>>>> public static void sleep(long _millisec) {
>>>>>>> try {
>>>>>>> Thread.sleep(_millisec);
>>>>>>> } catch (InterruptedException e) {
>>>>>>> log.i(e);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> This will output
>>>>>>>
>>>>>>> Wait for Ctrl-C - off
>>>>>>> Wait for Ctrl-C - on
>>>>>>> Wait for Ctrl-C - off
>>>>>>> Wait for Ctrl-C - on
>>>>>>> ...
>>>>>>>
>>>>>>> If I interrupt, it will be separated from gogo shell and iterate for ever. - And I see the interrupted exception in the log.
>>>>>>>
>>>>>>> Thx,
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Karaf Commands and Cltr-C
Posted by Guillaume Nodet <gn...@apache.org>.
The Ctrl+C default behavior in Karaf is to to call Thread.interrupt().
The effect depends on what the thread is doing, you'll find more
information at [1].
If you want the command to be interrupted, the code needs to support it
correctly.
[1]
https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html
Cheers,
Guillaume Nodet
Le sam. 14 mars 2020 à 20:45, Mike Hummel <mh...@mhus.de> a écrit :
> The problem is if I not listen to ctrl-c in the moment of the interrupt
>
> while(true) {
> 1) do something
> 2) Thread.sleep()
> }
>
> And the 'Interrupt' is while (1) and not in (2) then the cmd will not be
> interrupted. - I tested it.
>
> (The interrupt will be thrown in Thread.sleep() and (I think) in
> Object.wait(), but not in 'normal' executon or if try {} (catch Throwable)
> is used)
>
> It will not break the command loop but will move the command in background
> (correct: status == Done) and the cmd will not stop working.
>
> something like this would be nice
>
> while(true) {
> 1) something
> 2) Thread.sleep()
> 3) if (is canceled) break;
> }
>
> But (in 3) for the command it's not possible to check the status of
> execution. It's in org.apache.felix.gogo.runtime.CommandSessionImpl
>
> So using crtl-c to cancel the command execution is like roulette.
>
>
>
> On 14. Mar 2020, at 20:28, Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>
> CTRL-C just works fine in Karaf commands (including the one creating
> thread like log:tail).
>
> So, your use case is about intercepting CTRL-C yourself, right ? What’s
> the use case you want to achieve ?
>
> Regards
> JB
>
> Le 14 mars 2020 à 18:26, Mike Hummel <mh...@mhus.de> a écrit :
>
> Looks like it's not possible to block the ctrl-c event. It's implemented
> in felix gogo shell ans since every cmd (in a pipe) is executed in a
> separate thread it's not clear witch one should do the interruption control
>
> Maybe the feature "IGNORE_INTERRUPS" should not be offered.
>
> But felix should inform the commands if the execution is canceled. For
> example by checking for the Closeable interface and calling the close()
> method.
>
>
> On 14. Mar 2020, at 11:09, Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>
> Hi Mike,
>
> Let me take a look.
>
> Thanks for the report.
>
> Regards
> JB
>
> Le 14 mars 2020 à 09:03, Mike Hummel <mh...@mhus.de> a écrit :
>
> Hello,
>
> I did a little bit research for IGNORE_INTERRUPTS in the karaf sources. I
> found in master and karaf-4.2.x the same results.
>
> The const is defined in 'Sessio'n and 'SessionProperties', but only used
> from 'Session'.
>
> It is only used to enable the behaviour but never used to implement some
> kind of behaviour.
>
> Is there someone how can can prove this? And what is the background for
> two definitions of the same const? If I have the background I could look
> for a fix.
>
> Just now I created KARAF-6645 to track the problem.
>
> Best Regards,
>
> Mike
>
>
>
>
> On 5. Mar 2020, at 09:53, Mike Hummel <mh...@mhus.de> wrote:
>
> It's not easy to say ... In 4.2.3 it's broken and in 4.1.x it was ok.
>
> I testet the flag IGNORE_INTERRUPTS in 4.2.7 and it was not working as I
> imagine. I'm even not sure if the flag is exact what I want to do.
>
>
> On 4. Mar 2020, at 09:18, Guillaume Nodet <gn...@apache.org> wrote:
>
> Could you be more specific about "older releases" ? Do you know in which
> release it broke ?
>
> Le mer. 4 mars 2020 à 09:14, Mike Hummel <mh...@mhus.de> a écrit :
>
>> Hello,
>>
>> I try to break my karaf commands with Ctrl-C (e.g. by using
>> Thread.sleep()). In older releases this was no problem, but since the shell
>> starts every command in a separate thread the Cltr-C is also caught by gogo
>> and it will unlock the command from the console.
>>
>> I also tried this
>>
>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>
>> but it gets not the effect.
>>
>> Is there a way to recognise if the current command is separated from the
>> current gogo command line?
>>
>> A sample snipped:
>>
>> Object oldIgnoreInterrupts =
>> session.get(Session.IGNORE_INTERRUPTS);
>> try {
>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>> return doExecute(this, cmd, parameters);
>> } finally {
>> session.put(Session.IGNORE_INTERRUPTS, oldIgnoreInterrupts);
>> }
>>
>> public Object doExecute(CmdShitYo base, String cmd, String[]
>> parameters) throws Exception {
>> if (cmd.equals("ctrl-c")) {
>> try {
>> while (true) {
>> System.out.println("Wait for Ctrl-C - off");
>> MThread.sleep(3000);
>> }
>> } catch (InterruptedException e) {
>> System.out.println("Interrupted !!!!");
>> }
>> }
>> }
>>
>> MThread:
>> public static void sleep(long _millisec) {
>> try {
>> Thread.sleep(_millisec);
>> } catch (InterruptedException e) {
>> log.i(e);
>> }
>> }
>>
>> This will output
>>
>> Wait for Ctrl-C - off
>> Wait for Ctrl-C - on
>> Wait for Ctrl-C - off
>> Wait for Ctrl-C - on
>> ...
>>
>> If I interrupt, it will be separated from gogo shell and iterate for
>> ever. - And I see the interrupted exception in the log.
>>
>> Thx,
>>
>> Mike
>
>
>
> --
> ------------------------
> Guillaume Nodet
>
>
>
>
>
>
>
>
--
------------------------
Guillaume Nodet
Re: Karaf Commands and Cltr-C
Posted by Mike Hummel <mh...@mhus.de>.
Sorry in: org.apache.felix.gogo.runtime.CommandSessionImpl.JobImpl
> On 14. Mar 2020, at 20:45, Mike Hummel <mh...@mhus.de> wrote:
>
> org.apache.felix.gogo.runtime.CommandSessionImpl
Re: Karaf Commands and Cltr-C
Posted by Mike Hummel <mh...@mhus.de>.
The problem is if I not listen to ctrl-c in the moment of the interrupt
while(true) {
1) do something
2) Thread.sleep()
}
And the 'Interrupt' is while (1) and not in (2) then the cmd will not be interrupted. - I tested it.
(The interrupt will be thrown in Thread.sleep() and (I think) in Object.wait(), but not in 'normal' executon or if try {} (catch Throwable) is used)
It will not break the command loop but will move the command in background (correct: status == Done) and the cmd will not stop working.
something like this would be nice
while(true) {
1) something
2) Thread.sleep()
3) if (is canceled) break;
}
But (in 3) for the command it's not possible to check the status of execution. It's in org.apache.felix.gogo.runtime.CommandSessionImpl
So using crtl-c to cancel the command execution is like roulette.
> On 14. Mar 2020, at 20:28, Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>
> CTRL-C just works fine in Karaf commands (including the one creating thread like log:tail).
>
> So, your use case is about intercepting CTRL-C yourself, right ? What’s the use case you want to achieve ?
>
> Regards
> JB
>
>> Le 14 mars 2020 à 18:26, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>
>> Looks like it's not possible to block the ctrl-c event. It's implemented in felix gogo shell ans since every cmd (in a pipe) is executed in a separate thread it's not clear witch one should do the interruption control
>>
>> Maybe the feature "IGNORE_INTERRUPS" should not be offered.
>>
>> But felix should inform the commands if the execution is canceled. For example by checking for the Closeable interface and calling the close() method.
>>
>>
>>> On 14. Mar 2020, at 11:09, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>>
>>> Hi Mike,
>>>
>>> Let me take a look.
>>>
>>> Thanks for the report.
>>>
>>> Regards
>>> JB
>>>
>>>> Le 14 mars 2020 à 09:03, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>
>>>> Hello,
>>>>
>>>> I did a little bit research for IGNORE_INTERRUPTS in the karaf sources. I found in master and karaf-4.2.x the same results.
>>>>
>>>> The const is defined in 'Sessio'n and 'SessionProperties', but only used from 'Session'.
>>>>
>>>> It is only used to enable the behaviour but never used to implement some kind of behaviour.
>>>>
>>>> Is there someone how can can prove this? And what is the background for two definitions of the same const? If I have the background I could look for a fix.
>>>>
>>>> Just now I created KARAF-6645 to track the problem.
>>>>
>>>> Best Regards,
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>>
>>>>> On 5. Mar 2020, at 09:53, Mike Hummel <mh@mhus.de <ma...@mhus.de>> wrote:
>>>>>
>>>>> It's not easy to say ... In 4.2.3 it's broken and in 4.1.x it was ok.
>>>>>
>>>>> I testet the flag IGNORE_INTERRUPTS in 4.2.7 and it was not working as I imagine. I'm even not sure if the flag is exact what I want to do.
>>>>>
>>>>>
>>>>>> On 4. Mar 2020, at 09:18, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>>>>>
>>>>>> Could you be more specific about "older releases" ? Do you know in which release it broke ?
>>>>>>
>>>>>> Le mer. 4 mars 2020 à 09:14, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>>> Hello,
>>>>>>
>>>>>> I try to break my karaf commands with Ctrl-C (e.g. by using Thread.sleep()). In older releases this was no problem, but since the shell starts every command in a separate thread the Cltr-C is also caught by gogo and it will unlock the command from the console.
>>>>>>
>>>>>> I also tried this
>>>>>>
>>>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>>>>
>>>>>> but it gets not the effect.
>>>>>>
>>>>>> Is there a way to recognise if the current command is separated from the current gogo command line?
>>>>>>
>>>>>> A sample snipped:
>>>>>>
>>>>>> Object oldIgnoreInterrupts = session.get(Session.IGNORE_INTERRUPTS);
>>>>>> try {
>>>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>>>> return doExecute(this, cmd, parameters);
>>>>>> } finally {
>>>>>> session.put(Session.IGNORE_INTERRUPTS, oldIgnoreInterrupts);
>>>>>> }
>>>>>>
>>>>>> public Object doExecute(CmdShitYo base, String cmd, String[] parameters) throws Exception {
>>>>>> if (cmd.equals("ctrl-c")) {
>>>>>> try {
>>>>>> while (true) {
>>>>>> System.out.println("Wait for Ctrl-C - off");
>>>>>> MThread.sleep(3000);
>>>>>> }
>>>>>> } catch (InterruptedException e) {
>>>>>> System.out.println("Interrupted !!!!");
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> MThread:
>>>>>> public static void sleep(long _millisec) {
>>>>>> try {
>>>>>> Thread.sleep(_millisec);
>>>>>> } catch (InterruptedException e) {
>>>>>> log.i(e);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> This will output
>>>>>>
>>>>>> Wait for Ctrl-C - off
>>>>>> Wait for Ctrl-C - on
>>>>>> Wait for Ctrl-C - off
>>>>>> Wait for Ctrl-C - on
>>>>>> ...
>>>>>>
>>>>>> If I interrupt, it will be separated from gogo shell and iterate for ever. - And I see the interrupted exception in the log.
>>>>>>
>>>>>> Thx,
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Karaf Commands and Cltr-C
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
CTRL-C just works fine in Karaf commands (including the one creating thread like log:tail).
So, your use case is about intercepting CTRL-C yourself, right ? What’s the use case you want to achieve ?
Regards
JB
> Le 14 mars 2020 à 18:26, Mike Hummel <mh...@mhus.de> a écrit :
>
> Looks like it's not possible to block the ctrl-c event. It's implemented in felix gogo shell ans since every cmd (in a pipe) is executed in a separate thread it's not clear witch one should do the interruption control
>
> Maybe the feature "IGNORE_INTERRUPS" should not be offered.
>
> But felix should inform the commands if the execution is canceled. For example by checking for the Closeable interface and calling the close() method.
>
>
>> On 14. Mar 2020, at 11:09, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>
>> Hi Mike,
>>
>> Let me take a look.
>>
>> Thanks for the report.
>>
>> Regards
>> JB
>>
>>> Le 14 mars 2020 à 09:03, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>
>>> Hello,
>>>
>>> I did a little bit research for IGNORE_INTERRUPTS in the karaf sources. I found in master and karaf-4.2.x the same results.
>>>
>>> The const is defined in 'Sessio'n and 'SessionProperties', but only used from 'Session'.
>>>
>>> It is only used to enable the behaviour but never used to implement some kind of behaviour.
>>>
>>> Is there someone how can can prove this? And what is the background for two definitions of the same const? If I have the background I could look for a fix.
>>>
>>> Just now I created KARAF-6645 to track the problem.
>>>
>>> Best Regards,
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>>> On 5. Mar 2020, at 09:53, Mike Hummel <mh@mhus.de <ma...@mhus.de>> wrote:
>>>>
>>>> It's not easy to say ... In 4.2.3 it's broken and in 4.1.x it was ok.
>>>>
>>>> I testet the flag IGNORE_INTERRUPTS in 4.2.7 and it was not working as I imagine. I'm even not sure if the flag is exact what I want to do.
>>>>
>>>>
>>>>> On 4. Mar 2020, at 09:18, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>>>>
>>>>> Could you be more specific about "older releases" ? Do you know in which release it broke ?
>>>>>
>>>>> Le mer. 4 mars 2020 à 09:14, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>>> Hello,
>>>>>
>>>>> I try to break my karaf commands with Ctrl-C (e.g. by using Thread.sleep()). In older releases this was no problem, but since the shell starts every command in a separate thread the Cltr-C is also caught by gogo and it will unlock the command from the console.
>>>>>
>>>>> I also tried this
>>>>>
>>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>>>
>>>>> but it gets not the effect.
>>>>>
>>>>> Is there a way to recognise if the current command is separated from the current gogo command line?
>>>>>
>>>>> A sample snipped:
>>>>>
>>>>> Object oldIgnoreInterrupts = session.get(Session.IGNORE_INTERRUPTS);
>>>>> try {
>>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>>> return doExecute(this, cmd, parameters);
>>>>> } finally {
>>>>> session.put(Session.IGNORE_INTERRUPTS, oldIgnoreInterrupts);
>>>>> }
>>>>>
>>>>> public Object doExecute(CmdShitYo base, String cmd, String[] parameters) throws Exception {
>>>>> if (cmd.equals("ctrl-c")) {
>>>>> try {
>>>>> while (true) {
>>>>> System.out.println("Wait for Ctrl-C - off");
>>>>> MThread.sleep(3000);
>>>>> }
>>>>> } catch (InterruptedException e) {
>>>>> System.out.println("Interrupted !!!!");
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> MThread:
>>>>> public static void sleep(long _millisec) {
>>>>> try {
>>>>> Thread.sleep(_millisec);
>>>>> } catch (InterruptedException e) {
>>>>> log.i(e);
>>>>> }
>>>>> }
>>>>>
>>>>> This will output
>>>>>
>>>>> Wait for Ctrl-C - off
>>>>> Wait for Ctrl-C - on
>>>>> Wait for Ctrl-C - off
>>>>> Wait for Ctrl-C - on
>>>>> ...
>>>>>
>>>>> If I interrupt, it will be separated from gogo shell and iterate for ever. - And I see the interrupted exception in the log.
>>>>>
>>>>> Thx,
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>>
>>>>
>>>
>>
>
Re: Karaf Commands and Cltr-C
Posted by Mike Hummel <mh...@mhus.de>.
Looks like it's not possible to block the ctrl-c event. It's implemented in felix gogo shell ans since every cmd (in a pipe) is executed in a separate thread it's not clear witch one should do the interruption control
Maybe the feature "IGNORE_INTERRUPS" should not be offered.
But felix should inform the commands if the execution is canceled. For example by checking for the Closeable interface and calling the close() method.
> On 14. Mar 2020, at 11:09, Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>
> Hi Mike,
>
> Let me take a look.
>
> Thanks for the report.
>
> Regards
> JB
>
>> Le 14 mars 2020 à 09:03, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>
>> Hello,
>>
>> I did a little bit research for IGNORE_INTERRUPTS in the karaf sources. I found in master and karaf-4.2.x the same results.
>>
>> The const is defined in 'Sessio'n and 'SessionProperties', but only used from 'Session'.
>>
>> It is only used to enable the behaviour but never used to implement some kind of behaviour.
>>
>> Is there someone how can can prove this? And what is the background for two definitions of the same const? If I have the background I could look for a fix.
>>
>> Just now I created KARAF-6645 to track the problem.
>>
>> Best Regards,
>>
>> Mike
>>
>>
>>
>>
>>> On 5. Mar 2020, at 09:53, Mike Hummel <mh@mhus.de <ma...@mhus.de>> wrote:
>>>
>>> It's not easy to say ... In 4.2.3 it's broken and in 4.1.x it was ok.
>>>
>>> I testet the flag IGNORE_INTERRUPTS in 4.2.7 and it was not working as I imagine. I'm even not sure if the flag is exact what I want to do.
>>>
>>>
>>>> On 4. Mar 2020, at 09:18, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>>>
>>>> Could you be more specific about "older releases" ? Do you know in which release it broke ?
>>>>
>>>> Le mer. 4 mars 2020 à 09:14, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>>> Hello,
>>>>
>>>> I try to break my karaf commands with Ctrl-C (e.g. by using Thread.sleep()). In older releases this was no problem, but since the shell starts every command in a separate thread the Cltr-C is also caught by gogo and it will unlock the command from the console.
>>>>
>>>> I also tried this
>>>>
>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>>
>>>> but it gets not the effect.
>>>>
>>>> Is there a way to recognise if the current command is separated from the current gogo command line?
>>>>
>>>> A sample snipped:
>>>>
>>>> Object oldIgnoreInterrupts = session.get(Session.IGNORE_INTERRUPTS);
>>>> try {
>>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>> return doExecute(this, cmd, parameters);
>>>> } finally {
>>>> session.put(Session.IGNORE_INTERRUPTS, oldIgnoreInterrupts);
>>>> }
>>>>
>>>> public Object doExecute(CmdShitYo base, String cmd, String[] parameters) throws Exception {
>>>> if (cmd.equals("ctrl-c")) {
>>>> try {
>>>> while (true) {
>>>> System.out.println("Wait for Ctrl-C - off");
>>>> MThread.sleep(3000);
>>>> }
>>>> } catch (InterruptedException e) {
>>>> System.out.println("Interrupted !!!!");
>>>> }
>>>> }
>>>> }
>>>>
>>>> MThread:
>>>> public static void sleep(long _millisec) {
>>>> try {
>>>> Thread.sleep(_millisec);
>>>> } catch (InterruptedException e) {
>>>> log.i(e);
>>>> }
>>>> }
>>>>
>>>> This will output
>>>>
>>>> Wait for Ctrl-C - off
>>>> Wait for Ctrl-C - on
>>>> Wait for Ctrl-C - off
>>>> Wait for Ctrl-C - on
>>>> ...
>>>>
>>>> If I interrupt, it will be separated from gogo shell and iterate for ever. - And I see the interrupted exception in the log.
>>>>
>>>> Thx,
>>>>
>>>> Mike
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>>
>>>
>>
>
Re: Karaf Commands and Cltr-C
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi Mike,
Let me take a look.
Thanks for the report.
Regards
JB
> Le 14 mars 2020 à 09:03, Mike Hummel <mh...@mhus.de> a écrit :
>
> Hello,
>
> I did a little bit research for IGNORE_INTERRUPTS in the karaf sources. I found in master and karaf-4.2.x the same results.
>
> The const is defined in 'Sessio'n and 'SessionProperties', but only used from 'Session'.
>
> It is only used to enable the behaviour but never used to implement some kind of behaviour.
>
> Is there someone how can can prove this? And what is the background for two definitions of the same const? If I have the background I could look for a fix.
>
> Just now I created KARAF-6645 to track the problem.
>
> Best Regards,
>
> Mike
>
>
>
>
>> On 5. Mar 2020, at 09:53, Mike Hummel <mh@mhus.de <ma...@mhus.de>> wrote:
>>
>> It's not easy to say ... In 4.2.3 it's broken and in 4.1.x it was ok.
>>
>> I testet the flag IGNORE_INTERRUPTS in 4.2.7 and it was not working as I imagine. I'm even not sure if the flag is exact what I want to do.
>>
>>
>>> On 4. Mar 2020, at 09:18, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>>
>>> Could you be more specific about "older releases" ? Do you know in which release it broke ?
>>>
>>> Le mer. 4 mars 2020 à 09:14, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>>> Hello,
>>>
>>> I try to break my karaf commands with Ctrl-C (e.g. by using Thread.sleep()). In older releases this was no problem, but since the shell starts every command in a separate thread the Cltr-C is also caught by gogo and it will unlock the command from the console.
>>>
>>> I also tried this
>>>
>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>>
>>> but it gets not the effect.
>>>
>>> Is there a way to recognise if the current command is separated from the current gogo command line?
>>>
>>> A sample snipped:
>>>
>>> Object oldIgnoreInterrupts = session.get(Session.IGNORE_INTERRUPTS);
>>> try {
>>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>> return doExecute(this, cmd, parameters);
>>> } finally {
>>> session.put(Session.IGNORE_INTERRUPTS, oldIgnoreInterrupts);
>>> }
>>>
>>> public Object doExecute(CmdShitYo base, String cmd, String[] parameters) throws Exception {
>>> if (cmd.equals("ctrl-c")) {
>>> try {
>>> while (true) {
>>> System.out.println("Wait for Ctrl-C - off");
>>> MThread.sleep(3000);
>>> }
>>> } catch (InterruptedException e) {
>>> System.out.println("Interrupted !!!!");
>>> }
>>> }
>>> }
>>>
>>> MThread:
>>> public static void sleep(long _millisec) {
>>> try {
>>> Thread.sleep(_millisec);
>>> } catch (InterruptedException e) {
>>> log.i(e);
>>> }
>>> }
>>>
>>> This will output
>>>
>>> Wait for Ctrl-C - off
>>> Wait for Ctrl-C - on
>>> Wait for Ctrl-C - off
>>> Wait for Ctrl-C - on
>>> ...
>>>
>>> If I interrupt, it will be separated from gogo shell and iterate for ever. - And I see the interrupted exception in the log.
>>>
>>> Thx,
>>>
>>> Mike
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>>
>>
>
Re: Karaf Commands and Cltr-C
Posted by Mike Hummel <mh...@mhus.de>.
Hello,
I did a little bit research for IGNORE_INTERRUPTS in the karaf sources. I found in master and karaf-4.2.x the same results.
The const is defined in 'Sessio'n and 'SessionProperties', but only used from 'Session'.
It is only used to enable the behaviour but never used to implement some kind of behaviour.
Is there someone how can can prove this? And what is the background for two definitions of the same const? If I have the background I could look for a fix.
Just now I created KARAF-6645 to track the problem.
Best Regards,
Mike
> On 5. Mar 2020, at 09:53, Mike Hummel <mh...@mhus.de> wrote:
>
> It's not easy to say ... In 4.2.3 it's broken and in 4.1.x it was ok.
>
> I testet the flag IGNORE_INTERRUPTS in 4.2.7 and it was not working as I imagine. I'm even not sure if the flag is exact what I want to do.
>
>
>> On 4. Mar 2020, at 09:18, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>
>> Could you be more specific about "older releases" ? Do you know in which release it broke ?
>>
>> Le mer. 4 mars 2020 à 09:14, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
>> Hello,
>>
>> I try to break my karaf commands with Ctrl-C (e.g. by using Thread.sleep()). In older releases this was no problem, but since the shell starts every command in a separate thread the Cltr-C is also caught by gogo and it will unlock the command from the console.
>>
>> I also tried this
>>
>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>>
>> but it gets not the effect.
>>
>> Is there a way to recognise if the current command is separated from the current gogo command line?
>>
>> A sample snipped:
>>
>> Object oldIgnoreInterrupts = session.get(Session.IGNORE_INTERRUPTS);
>> try {
>> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>> return doExecute(this, cmd, parameters);
>> } finally {
>> session.put(Session.IGNORE_INTERRUPTS, oldIgnoreInterrupts);
>> }
>>
>> public Object doExecute(CmdShitYo base, String cmd, String[] parameters) throws Exception {
>> if (cmd.equals("ctrl-c")) {
>> try {
>> while (true) {
>> System.out.println("Wait for Ctrl-C - off");
>> MThread.sleep(3000);
>> }
>> } catch (InterruptedException e) {
>> System.out.println("Interrupted !!!!");
>> }
>> }
>> }
>>
>> MThread:
>> public static void sleep(long _millisec) {
>> try {
>> Thread.sleep(_millisec);
>> } catch (InterruptedException e) {
>> log.i(e);
>> }
>> }
>>
>> This will output
>>
>> Wait for Ctrl-C - off
>> Wait for Ctrl-C - on
>> Wait for Ctrl-C - off
>> Wait for Ctrl-C - on
>> ...
>>
>> If I interrupt, it will be separated from gogo shell and iterate for ever. - And I see the interrupted exception in the log.
>>
>> Thx,
>>
>> Mike
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>
Re: Karaf Commands and Cltr-C
Posted by Mike Hummel <mh...@mhus.de>.
It's not easy to say ... In 4.2.3 it's broken and in 4.1.x it was ok.
I testet the flag IGNORE_INTERRUPTS in 4.2.7 and it was not working as I imagine. I'm even not sure if the flag is exact what I want to do.
> On 4. Mar 2020, at 09:18, Guillaume Nodet <gn...@apache.org> wrote:
>
> Could you be more specific about "older releases" ? Do you know in which release it broke ?
>
> Le mer. 4 mars 2020 à 09:14, Mike Hummel <mh@mhus.de <ma...@mhus.de>> a écrit :
> Hello,
>
> I try to break my karaf commands with Ctrl-C (e.g. by using Thread.sleep()). In older releases this was no problem, but since the shell starts every command in a separate thread the Cltr-C is also caught by gogo and it will unlock the command from the console.
>
> I also tried this
>
> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>
> but it gets not the effect.
>
> Is there a way to recognise if the current command is separated from the current gogo command line?
>
> A sample snipped:
>
> Object oldIgnoreInterrupts = session.get(Session.IGNORE_INTERRUPTS);
> try {
> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
> return doExecute(this, cmd, parameters);
> } finally {
> session.put(Session.IGNORE_INTERRUPTS, oldIgnoreInterrupts);
> }
>
> public Object doExecute(CmdShitYo base, String cmd, String[] parameters) throws Exception {
> if (cmd.equals("ctrl-c")) {
> try {
> while (true) {
> System.out.println("Wait for Ctrl-C - off");
> MThread.sleep(3000);
> }
> } catch (InterruptedException e) {
> System.out.println("Interrupted !!!!");
> }
> }
> }
>
> MThread:
> public static void sleep(long _millisec) {
> try {
> Thread.sleep(_millisec);
> } catch (InterruptedException e) {
> log.i(e);
> }
> }
>
> This will output
>
> Wait for Ctrl-C - off
> Wait for Ctrl-C - on
> Wait for Ctrl-C - off
> Wait for Ctrl-C - on
> ...
>
> If I interrupt, it will be separated from gogo shell and iterate for ever. - And I see the interrupted exception in the log.
>
> Thx,
>
> Mike
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Karaf Commands and Cltr-C
Posted by Guillaume Nodet <gn...@apache.org>.
Could you be more specific about "older releases" ? Do you know in which
release it broke ?
Le mer. 4 mars 2020 à 09:14, Mike Hummel <mh...@mhus.de> a écrit :
> Hello,
>
> I try to break my karaf commands with Ctrl-C (e.g. by using
> Thread.sleep()). In older releases this was no problem, but since the shell
> starts every command in a separate thread the Cltr-C is also caught by gogo
> and it will unlock the command from the console.
>
> I also tried this
>
> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
>
> but it gets not the effect.
>
> Is there a way to recognise if the current command is separated from the
> current gogo command line?
>
> A sample snipped:
>
> Object oldIgnoreInterrupts =
> session.get(Session.IGNORE_INTERRUPTS);
> try {
> session.put(Session.IGNORE_INTERRUPTS, Boolean.TRUE);
> return doExecute(this, cmd, parameters);
> } finally {
> session.put(Session.IGNORE_INTERRUPTS, oldIgnoreInterrupts);
> }
>
> public Object doExecute(CmdShitYo base, String cmd, String[]
> parameters) throws Exception {
> if (cmd.equals("ctrl-c")) {
> try {
> while (true) {
> System.out.println("Wait for Ctrl-C - off");
> MThread.sleep(3000);
> }
> } catch (InterruptedException e) {
> System.out.println("Interrupted !!!!");
> }
> }
> }
>
> MThread:
> public static void sleep(long _millisec) {
> try {
> Thread.sleep(_millisec);
> } catch (InterruptedException e) {
> log.i(e);
> }
> }
>
> This will output
>
> Wait for Ctrl-C - off
> Wait for Ctrl-C - on
> Wait for Ctrl-C - off
> Wait for Ctrl-C - on
> ...
>
> If I interrupt, it will be separated from gogo shell and iterate for ever.
> - And I see the interrupted exception in the log.
>
> Thx,
>
> Mike
--
------------------------
Guillaume Nodet