Inventor's Paradox

Overview Red Hat  has augmented docker's registry with some enhancement before deploying it in Openshift cluster. In some cases we might want to debug it, to find out reasons why some stuff doesn't work or for educational purposes. In this post we will describe steps required to do debugging for the docker registry (a.k.a docker distribution) from Visual Studio Code. We are going to run the openshift docker registry in a separate deployment config. Repository identification First, docker registry is created using Go Language; and in this case, the source code for the enhanced docker registry lives in github repository  https://github.com/openshift/origin for some versions and in  https://github.com/openshift/docker-distribution for later versions. In this post I will use the version in openshift 3.6 ( https://github.com/openshift/origin/tree/v3.6.1 ) because of selfish reasons our sandbox/development openshift cluster uses this version. The main source code file lives...

When running an application in the server, sometimes things doesn't goes the way it supposed to be, and we need to debug the application. For desktop application based on Java or .NET technology, it is just a matter of setting the breakpoint in IDE and then running the application with debug enabled. For web application based on ASP.NET, similar thing could be done by using Visual Studio and running the web application in debug mode using IIS Express. But what about web services that being served by SAP Netweaver AS ? This post shows how. Option 1. Execute - Debugging in SE37 This is the most standard way to debug ABAP remote function module. Just open up transaction SE37, type function module name, and click on the caliper icon  (For those who are not so into STEM stuffs, you could see this wiki page to know about calipers). Then fill in the input parameters before clicking on the Execute - Debugging icon. Now you are inside the ABAP debugger, and ...

In this post I record steps that I took to debug some ruby code. Actually the code was an ruby mcollective server code that were installed as part of openshift origin Node. The bug is that the server consistently fails to respond to client queries in my configuration. I documented the steps taken  even though I hadn't nailed the bug yet. First thing first First we need to identify the entry point. These commands would do the trick: [root@broker ~]# service ruby193-mcollective status mcollectived (pid  1069) is running... [root@broker ~]# ps afxw | grep 1069  1069 ?        Sl     0:03 ruby /opt/rh/ruby193/root/usr/sbin/mcollectived --pid=/opt/rh/ruby193/root/var/run/mcollectived.pid --config=/opt/rh/ruby193/root/etc/mcollective/server.cfg 12428 pts/0    S+     0:00          \_ grep 1069 We found out that the service is : running with pid 1069 running with configuration file /opt/rh...

Background Murphy's law describe that if something could break, it would break in the worst time possible. Or something like that. Anyway, more often than not, our software doesn't behave as it should. And I often get web apps that waiting endlessly for something. It made us curious what on earth cause the app to wait. In this case, the app is openshift origin console. Being Ruby based, means there supposedly a way to dump stack from running threads.  Technique At first I tried to borrow the openshift ruby cartridge method of thread dump. Upon reverse engineering the cartridge (ok, I just snoop in some files such as this ) I am surprised to find out that all that the ruby cartridge does is to send signal ABRT to the process which has the title prefix of Rack: .  Trying to apply the same procedure to the running openshift-console process, and the result is a killed process and a confusion. Another reference, the Phusion Passenger user's guide , tells me that Ruby...