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 <m...@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 <j...@nanthrax.net
>> <mailto:j...@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 <m...@mhus.de <mailto:m...@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 <gno...@apache.org
>>>> <mailto:gno...@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 <m...@mhus.de
>>>> <mailto:m...@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 <j...@nanthrax.net
>>>>> <mailto:j...@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 <m...@mhus.de
>>>>>> <mailto:m...@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 <j...@nanthrax.net
>>>>>>> <mailto:j...@nanthrax.net>> wrote:
>>>>>>>
>>>>>>> Hi Mike,
>>>>>>>
>>>>>>> Let me take a look.
>>>>>>>
>>>>>>> Thanks for the report.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>> Le 14 mars 2020 à 09:03, Mike Hummel <m...@mhus.de
>>>>>>>> <mailto:m...@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 <m...@mhus.de
>>>>>>>>> <mailto:m...@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 <gno...@apache.org
>>>>>>>>>> <mailto:gno...@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 <m...@mhus.de
>>>>>>>>>> <mailto:m...@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
>>>>
>>>
>>
>
