Posts

Karaf 4.2.x and BRACKETED_PASTE

Since karaf 4.2.x (since I migrated from 4.0.10 to 4.2.2 and higher) I recognises a new feature in karaf console if copy and paste. If paste multi line content it will not pasted as single commands. Instead it will be pasted as a block and executed at once.

This feature is useful in some situations but in some it's also useful to work with the 'old style mode' - line by line.

Another problem is that exiting the karaf console with escape sequences, e.g. in docker attach mode (ctrl+p-q) the BRACKETED_PASTE mode will not be disabled and you have to disable it manually by typing

printf "\e[?2004l"
but it's not possible to paste it in this moment...
To switch between the modes I found the reason for the behaviour in the LineReader from jline 3. The reader can be configured to enable and disable the option and is accessible in the karaf console by the parameter '.jline.reader' Use the command
$.jline.reader option BRACKETED_PASTE false
to disable the option …

MHU Version String Definition

In the last years I see a wide range of different version string definitions. In the last years more and more one digit only versioning becoming more and more popular. See also Wikipedia.

I prefer the notation with three or more numbers but in a different meaning as common: <core>.<major>.<minor>[.<hotfix>]

The core version describes a common structure or technology change. Most of the time it's the same. The core version only changes if the central structure or idea is changed. E.g. if switching from 'all in one' to a modular architecture.

The major version will increase if for example all dependencies are updated and the project must be reorganised therefore.

The minor version will change for every bundle of hot fixes and changes.

The hotfix version will only be set if a small important fix is needed without to update the hole project.

Lambda analyse hack no more working in java 12

To bring errors in compile time I'm using java function references to refer object based queries. Since it is not possible to lookup the referenced function name (in fact a stupid behaviour) I was forced to use a hack to get the referenced name.

Now it looks like the hack and even no other way exists to get the function name in java 12 (and maybe in earlier versions). I tested the current openjdk12 against my tool and it looks like it's not working.

Therefore I switched the way to save my code consistency. The alternative way is to generate classes which are containing information about the existing function names.

A maven plugin analyses existing classes and generates new ones. The generated classes will only be updated if the content is changes. In this way it is possible to commit the classes to the software repository.

To switch your project you need to add the plugin configuration to your pom:

<plugin>
<groupId>de.mhus.lib</groupId>
<artifactId>constg…

Prepare karaf shell settings to work with mhu-osgi-tools

In karaf it's possible to configure a bashrc like file. This file will be executed every time a new gogo shell is opened. See scripting.adoc for details.

You can edit the file etc/shell.init.script and append the lines

console set logtail -c mhus:log settrail
this will activate useful mhu-osgi-tools settings for the console.

First line change the current console settings to work with karaf console. Second send the log to console output. Only console local log entries. Last line will enable debug output to printed also to console. So you get deeper feedback to executed commands direct in the console.

Highlight outputs in karaf gogo shell

The command shell:highlight in mhus-osgi-tools 1.3.5 will provide a command to search and highlight text via pipe:
The basic usage are:
service:list | highlight bundle
The command accept regex expressions and by default the regex is case insensitive, the result is:
[org.osgi.service.url.URLStreamHandlerService] ----------------------------------------------  service.bundleid = 51  service.id = 31  service.scope = singleton  url.handler.protocol = [wrap] Provided by :   OPS4J Pax Url - wrap: (51) Used by:   Apache Karaf :: Deployer :: Wrap Non OSGi Jar (28)  System Bundle (0)
More complex is the the option to search multiple words and change the color for each finding:
service:list | highlight \#blue bundle \#green service
The result:
[org.osgi.service.url.URLStreamHandlerService] ---------------------------------------------- service.bundleid = 51 service.id = 31 service.scope = singleton  url.handler.protocol = [wrap] Provided by :   OPS4J Pax Url - wrap: (51) Used by:   Apache Karaf :: Deployer :: Wrap No…

Update: Test your available CPU resources in karaf

In the new version coming up with mhus-osgi-tools 1.3.3 the test automatically adjust thread amount. It increase the thread count up to a level no more CPU time can be consumed.

Here an example from my laptop using the autoInfo=true parameter to see how the algorithm is working:

karaf@root()> shityo stress autoInfo=true Used cpu nanoseconds per second ... CPU Time: 0 -> 0 = 0%, Threads: 1 Auto up 1: [2] 998M 997M = 1.996G CPU Time: 0 -> 1996520601 = 100%, Threads: 2 Auto up 2: [3] 995M 999M 997M = 2.992G CPU Time: 1996520601 -> 2992796194 = 33%, Threads: 3 Auto up 3: [4] 998M 998M 998M 998M = 3.994G CPU Time: 2992796194 -> 3994464892 = 25%, Threads: 4 Auto up 4: [5] 998M 998M 998M 998M 998M = 4.992G CPU Time: 3994464892 -> 4992347050 = 19%, Threads: 5 Auto up 5: [6] 998M 998M 999M 999M 997M 998M = 5.991G CPU Time: 4992347050 -> 5991369437 = 16%, Threads: 6 Auto up 6: [7] 997M 994M 998M 997M 997M 997M 996M = 6.979G CPU Time: 5991369437 -> 6979148659 = 14%, Threads: 7 Auto up 7: [8] 99…

Test your available CPU resources in karaf

Times ago we start developing a fun tool to provoke extreme situations like out of memory or stack trace exception.  Now I added a new feature to stress the CPU. I also count the used time on the CPU to see how much CPU time is 'available'.

Using the tool is a good indicator to show how much CPU time is available for the JVM. Specially in virtual environments this information is useful. But you need to set parameters carefully. Don't stress the CPU too long at once and use a sleep between the test cycles. So the hypervisor is not moving other VM guests out of your system and the result is valide.

Naughty: Stress the CPU for a longer time and the VM host is yours.

Install mhus-osgi-commands and use:
shityo stress This example from my laptop:
karaf@root()> shityo stress threads=8 Used cpu nanoseconds per second ... 1: [8] 995M 982M 992M 994M 993M 996M 964M 996M = 7.916G 2: [8] 994M 995M 992M 996M 990M 994M 995M 993M = 7.951G 3: [8] 999M 998M 999M 998M 999M 997M 998M 997M = 7.98…