Karaf Commands and Cltr-C

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Karaf Commands and Cltr-C

Mike Hummel
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
Reply | Threaded
Open this post in threaded view
|

Re: Karaf Commands and Cltr-C

Guillaume Nodet-2
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Karaf Commands and Cltr-C

Mike Hummel
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 <[hidden email]> 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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Karaf Commands and Cltr-C

Mike Hummel
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Karaf Commands and Cltr-C

jbonofre
Hi Mike,

Let me take a look.

Thanks for the report.

Regards
JB

Le 14 mars 2020 à 09:03, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: Karaf Commands and Cltr-C

Mike Hummel
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 <[hidden email]> wrote:

Hi Mike,

Let me take a look.

Thanks for the report.

Regards
JB

Le 14 mars 2020 à 09:03, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: Karaf Commands and Cltr-C

jbonofre
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 <[hidden email]> 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 <[hidden email]> wrote:

Hi Mike,

Let me take a look.

Thanks for the report.

Regards
JB

Le 14 mars 2020 à 09:03, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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






Reply | Threaded
Open this post in threaded view
|

Re: Karaf Commands and Cltr-C

Mike Hummel
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

Hi Mike,

Let me take a look.

Thanks for the report.

Regards
JB

Le 14 mars 2020 à 09:03, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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







Reply | Threaded
Open this post in threaded view
|

Re: Karaf Commands and Cltr-C

Mike Hummel
Sorry in: org.apache.felix.gogo.runtime.CommandSessionImpl.JobImpl

On 14. Mar 2020, at 20:45, Mike Hummel <[hidden email]> wrote:

org.apache.felix.gogo.runtime.CommandSessionImpl

Reply | Threaded
Open this post in threaded view
|

Re: Karaf Commands and Cltr-C

Guillaume Nodet-2
In reply to this post by Mike Hummel
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.


Cheers,
Guillaume Nodet


Le sam. 14 mars 2020 à 20:45, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

Hi Mike,

Let me take a look.

Thanks for the report.

Regards
JB

Le 14 mars 2020 à 09:03, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Karaf Commands and Cltr-C

Mike Hummel
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 <[hidden email]> 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.


Cheers,
Guillaume Nodet


Le sam. 14 mars 2020 à 20:45, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

Hi Mike,

Let me take a look.

Thanks for the report.

Regards
JB

Le 14 mars 2020 à 09:03, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Karaf Commands and Cltr-C

jbonofre
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 <[hidden email]> 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 <[hidden email]> 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.


Cheers,
Guillaume Nodet


Le sam. 14 mars 2020 à 20:45, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

Hi Mike,

Let me take a look.

Thanks for the report.

Regards
JB

Le 14 mars 2020 à 09:03, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Karaf Commands and Cltr-C

Mike Hummel
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.


But it looks like this is another topic. But is it karaf or felix?



On 15. Mar 2020, at 06:03, Jean-Baptiste Onofre <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Cheers,
Guillaume Nodet


Le sam. 14 mars 2020 à 20:45, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

Hi Mike,

Let me take a look.

Thanks for the report.

Regards
JB

Le 14 mars 2020 à 09:03, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: Karaf Commands and Cltr-C

jbonofre
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 <[hidden email]> 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.


But it looks like this is another topic. But is it karaf or felix?



On 15. Mar 2020, at 06:03, Jean-Baptiste Onofre <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Cheers,
Guillaume Nodet


Le sam. 14 mars 2020 à 20:45, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

Hi Mike,

Let me take a look.

Thanks for the report.

Regards
JB

Le 14 mars 2020 à 09:03, Mike Hummel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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