Paho MQTT client, max in-flight messages for QoS > 0

Working with MQTT protocol in Java usually means using Eclipse Paho FOSS library as a client (it’s even used by Spring for MQTT support in Spring Messaging).

Using Paho to send messages with Quality of Service (QoS) bigger than zero though might result in error/exception “Too many publishes in progress” in case many messages are sent in short period of time.

The straightforward fix to that is of-course not to use QoS other than zero, but there are other ways to remedy that problem.

Continue reading

ActiveMQ disable Diffie-Hellman ciphers to avoid “KeyUsage does not allow digital signatures” errors

Here’s how to do it:


Add this parameter to URI in mqtt transportConnector (in your conf/activemq.xml config).

The need for this? I had a set of keys+certificates that were working perfectly fine on RabbitMQ, but on ActiveMQ I was getting “KeyUsage does not allow digital signatures” errors on client when it was validating server’s certificate.

I had no idea why this happened, googling revealed some fragmented info, in general I understood that my server’s certificate had “extension” “key usage” that indicated it didn’t allow (support?) digital signatures.

Screen Shot 2016-05-31 at 11.50.27 PM

Continue reading

Raspberry Pi Raspbian Jesse – free serial port ttyAMA0

I’ve posted the answer at stackexchange.

In short, disabling terminal on serial via raspi-config (advanced->Serial) should do the trick.

It it doesn’t for some reason – commenting out ttyAMA0 from /boot/cmdline.txt and disabling serial-getty via sudo systemctl mask serial-getty@ttyAMA0.service should definitely free the port.

But still one must manually set pins 15 and 16 into ALT0 state. Command-line “gpio” utility can be used for that:
gpio mode 15 ALT0
gpio mode 16 ALT0

Don’t do the manual pin ALT0 mode setting – enable UART in /boot/config.txt instead (find enable_uart=0 and change to enable_uart=1).
This will ensure /dev/ttyAMA0 will exist. Otherwise it may not exist.

Move MP3s into folders by “Artist – Album – Year” in OS X

Quasi one-liner:

for filename in *.mp3; do; ART=$(mdls -name kMDItemAuthors -raw $filename | tr -d '\n"()' | awk '{$1=$1};1'); ALB=$(mdls -raw -name kMDItemAlbum $filename); YR=$(mdls -raw -name kMDItemRecordingYear $filename); echo $ART - $ALB - $YR - $filename; mkdir -p "$ART - $ALB - $YR"; mv $filename "./$ART - $ALB - $YR/"; done

Same, but on multiple lines:

for filename in *.mp3
  ART=$(mdls -name kMDItemAuthors -raw $filename | tr -d '\n"()' | awk '{$1=$1};1')
  ALB=$(mdls -raw -name kMDItemAlbum $filename)
  YR=$(mdls -raw -name kMDItemRecordingYear $filename)
  echo $ART - $ALB - $YR - $filename
  mkdir -p "$ART - $ALB - $YR"
  mv $filename "./$ART - $ALB - $YR/"

Spring Boot and Tomcat7

I had an issue with Spring Boot app @ Tomcat7 – the app was running fine at Tomcat8, but at Tomcat7 it wasn’t starting.

The app is using web.xml-less method – some class extends SpringBootServletInitializer and is annotated with @SpringBootApplication annotation. Again, this is sufficient at Tomcat8 for some reason, but not for Tomcat7.

Tomcat7 is Servlet 3.0, Spring Boot recent versions use Servler 3.1, as is Tomcat8, and this was part of the problem – because maven generated eclipse project was really willing to use Servlet 3.1 facet, which made it impossible to deploy to Tomcat7 with WTP.

In order to fix that, not only servlet version 3.0.1 but also Tomcat version 7.0.x had to be declared in pom. Then eclipse project had to be deleted (with all it’s dot meta files and folders) and recreated – this made it possible for me to at least deploy to Tomcat7 from Eclipse with WTP. Whew.

But – the app wasn’t starting. It was deployed, but Spring servlet didn’t register, no Spring contexts were initialized, etc.

It took me several hours to find a solution – and I’ve stumbled over it almost accidentally online. It turns out it’s insufficient for your @SpringBootApplication annotated class to just extend SpringBootServletInitializer – it should also explicitly implement WebApplicationInitializer! That’s it! This has fixed the issue – the app was running again.

I guess this is somehow required by the whole @HandlesTypes driven thing in servlet 3.0, but it is quite weird it works differently in servlet 3.1. Or is it just Tomcat? Well, apparently people are complaining about the same issue on… WebLogic.

Anyhow, the solution is found.

P.S. Just when I thought I’m done – I’ve run into same issue again, but on different environment – the problem moved from dev to test. Damn! I also had a bit older Tomcat on test, so checked with that version locally – worked fine. So took me a bit more to figure out switch from Java7 to Java8 is needed to fix the problem. Now I’m absolutely puzzled regarding the causes, but anyhow, the WebApplicationInitializer and Java8 made it work. Finally!

Grape config for local maven repo

Here’s my new grape config that I’ve made to have proper support for local maven repository (UPD: fixed missing transitive dependencies – thanks to this StackOverflow question – ivy pattern should have POM extension):

  <settings defaultResolver="downloadGrapes"/>
  <property name="m2-pattern" value="${user.home}/.m2/repository/[organisation]/[module]/[revision]/[module]-[revision](-[classifier]).[ext]" />
  <property name="m2-pattern-ivy" value="${user.home}/.m2/repository/[organisation]/[module]/[revision]/[module]-[revision](-[classifier]).pom" />
    <cache name="nocache" useOrigin="true" />
    <chain name="downloadGrapes">
      <filesystem name="local-maven2" checkmodified="true" changingPattern=".*" changingMatcher="regexp" m2compatible="true" cache="nocache">
        <artifact pattern="${m2-pattern}"/>
        <ivy pattern="${m2-pattern-ivy}"/>
      <filesystem name="cachedGrapes">
        <ivy pattern="${user.home}/.groovy/grapes/[organisation]/[module]/ivy-[revision].xml"/>
        <artifact pattern="${user.home}/.groovy/grapes/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
      <!-- todo add 'endorsed groovy extensions' resolver here -->
      <ibiblio name="ibiblio" m2compatible="true"/>
      <ibiblio name="codehaus" root="" m2compatible="true"/>
      <ibiblio name="java.net2" root="" m2compatible="true"/>


Previously I’ve had local maven repo declared this way:

<ibiblio name="local" root="file:${user.home}/.m2/repository/" m2compatible="true"/>

This introduced two issues: I did not have latest versions of SNAPSHOT libraries due to caching made by grape, and I had two copies of same libraries on my machine for the same reason – one in grape cache and one in local maven repo.

No combination of checkmodified, changingPattern and/or changingMatcher solved this – the repo was considered remote and thus subject to caching by default cache.

So two things were made here – the repo was declared via filesystem in order to indicate that it’s a local repo, and “nocache” cache with useOrigin=”true” was specifically set for it, making grape only keep grape config xmls in cache, but not copy actual JARs, and always get latest versions as they are in .m2 folder.

Now some credit to the author – the fix was found in this StackOverlow question, asked and auto-answered by Jean-Philippe Pellet. Thanks mr.Pellet!

P.S. If something doesn’t get resolved – don’t panick, just try removing it from ivy cache first and then re-grab.

IE8 + Selenium Remote WebDriver + Progressive IE ( == death

There is some weird issue with Internet Explorer WebDriver that I’ve encountered in IE8 (not sure about newer IE versions) – the image with URL “about:blank” causes WebDriver to be stuck forever in “1 item remaining (downloading picture about:blank)”.

Looks like it has never been resolved.

It also turned out that in my case “about:blank” images were coming from Progressive IE which seems to be using it for background images for some reason (see screenshot of part of PIE2 code for an example of such image).

Disabling PIE in test mode solved the issue. Though other people had it in different cases with different workarounds.

Be advised. Continue reading