I’ve just run into a weird problem where RabbitMQ server was running EXTREMELY slow on my laptop for no apparent reason.
After trying a bunch of things and googlig for a while I’ve found out that possible reason for that might be slow host resolution. But everything was running on a localhost!
I’ve checked my /etc/hosts and found out… Well, when I’ve upgraded my MacBook Pro laptop I’ve imported all stuff from previous one (using Apple’s migration assistant), but also did change the new laptop’s network name to avoid conflicts with the old laptop being on the same network. But I did not update /etc/hosts accordingly – it only had 127.0.0.1 associated with the old network name.
Apparently, this is a big deal for RabbitMQ. I’ve been running it like that for more than a month and had no issues with any software whatsoever so far – but RabbitMQ (or possibly the underlying Erlang VM) was doing some special name resolution using my computer network name apparently, and that just didn’t work. Causing it not to report any errors though, but just run EXTREMELY (I mean it!) slow.
Today I had to build kube-state-metrics Kubernetes extra metrics exporter for Prometheus monitoring system. I wanted to build it for specific Linux (kernel) version (in my case it was Alpine Linux 3.4), and I also wanted to build a specific version of kube-state-metrics – latest stable, which is 1.3.1 currently.
I didn’t want to get latest version from master as I was not sure about it’s stability and I would have hard time re-creating the build since master would move on over time, so simply making “go get” wasn’t an option.
The process turned out to be a bit tricky – I wanted to use docker to have proper version of Go lang for Alpine Linux 3.4 while I’m on a macOS myself, but the makefile of kube-state-metrics also uses docker (for whatever silly reason that is), so I needed to build it using go build.
As it turned out, I had to do two things – install Go into Alpine 3.4 (which took some copypasting from https://github.com/docker-library/golang where they have Dockerfile for Alpine 3.7 – contents of which I used) and then get the paths right for GOPATH in order to build kube-state-metrics.
Here’s the resulting Dockerfile: Continue reading
I’ve been using successfully my 2.8″ 320×240 uTouch PiTFT with Raspberry Pi 1 and 2, but recently I’ve tried it with Pi 3 and got a 90-degree rotated touch input.
I’ve installed PiTFT support using adafruit-pitft-helper and this instruction at Adafruit. However, if did not help with the rotated input issue.
What did help was this StackOverflow answer and this manual on transformation matrix.
In short, I had to edit /usr/share/X11/xorg.conf.d/40-libinput.conf adding this to “libinput touchscreen catchall” section:
Option "TransformationMatrix" "0 -1 1 1 0 0 0 0 1"
This is a transformation matrix for 90 degree rotation of screen, which was the case for me.
Once done, the touchscreen input has got proper rotation.
Spring MVC has nice feature for adding security controls to Controller methods via @PreAuthorize annotation, but there’s an interesting problem that might occur when those methods are mistakenly marked as private or final.
Spring uses CGLib proxy to add calls to authorization logic declared in @PreAuthorize before calling actual controller method, but CGLib fails to process private or final methods, producing error like this in console:
2016-11-28 17:19:14.186 INFO 97079 --- [ main] o.s.aop.framework.CglibAopProxy : Unable to proxy method [public final java.util.Map com.package.controller.MyController.someMethod(javax.servlet.http.HttpServletResponse)] because it is final: All calls to this method via a proxy will NOT be routed to the target instance.
Well, so far so good – nothing special happens, all is more/less expected.
The problem though is that among most console output produced by Spring MVC yet another INFO log line rarely gets noticed. So what actually happens with those private/final methods of SpringMVC controller? Here weird stuff begins.
Say you’re writing a controller method that has a @PreAuthorize added to it, and accidentally copy-paste in a return type with final predicate before it, thus making your method final. You miss the log line in console because it’s just INFO among many other similar lines. And then… all autowired or otherwise injected fields of a controller are somehow null when calling only that particular method. But we know that in Spring MVC every controller is a singleton, so how is this even possible?
The issue appears to be that we’re actually calling methods on a CGLib proxy, that can’t pass them down to actual controller class instance. But proxy itself looks just like the controller class instance, except all fields that were supposed to be injected by Spring are null. A weird looking symptom which does not intuitively lead us to the cause of the problem.
But once one encounters this issue, I bet one remembers well next time what it is a symptom of.
P.S. I’ve encountered this issue with final method, but seems other people had same issue with private methods.
I had a problem with Docker on Mac OS X – nowadays it comes with xHyve VM instead of VirtualBox, and the VM uses cow2 format for it’s disk image, so it wasn’t clear how can one access files in /var/lib/docker on the VM.
Why does one even have to access the files? Well, there can be number of reasons. In my case it was Mosquitto container where Mosquitto MQTT broker is a PID 1 process, and when it’s not running – the container isn’t running either. So while changing a config file for Mosquitto I had to do some experimenting, which caused Mosquitto to fail on startup due to bad configuration.
As you can probably guess, it wasn’t possible to fix Mosquitto config otherwise than via /var/lib/docker, because I could not start the container anymore. So it was either this, or start from scratch with new container.
Anyhow, I did not find any working way to mount cow2 image, but I have found a solution on Docker forums to get terminal into xHyve VM when docker was started:
The username is root with no password.
Thanks to Rohinton Kazak for posting that answer.
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.