The ‘simple-vertx’ can not call the ‘hello-vertx’. Okapi records Thread Blocked!

I want to make modules call each other. As the guide mentioned, the ‘simple-vertx’ project is aimed to call ‘hello-vertx’. . I have to mention that I have already configured the ‘docker.service’ file , and Okapi is started by the commond ’ java -Dokapiurl=“http://:9130$OKAPIHOST” -jar xxxx.jar dev ', and my ‘hostname’ is ‘liucxPC’ rather than ‘localhost’.

First I run ‘runhello.sh’, and then ‘runsimple.sh’, these 2 modules are successfully deployed and enabled for ‘testlib’ tenant. The ‘/hello’ interface runs well, but when I send GET request to ‘/simple’ interface with ‘X-Okapi-Tenant:testlib’ header , a message of “Hello failed with java.nio.channels.UnresolvedAddressException” returned. Meanwhile the okapi’s console reports the similar informations, but with ‘Thread bolcked’ before the message “OkapiClient exception: java.nio.channels.UnresolvedAddressException : null”.
Then I tried to call ‘xxx.xxx.x.xx:9132/simple’ directly where the ‘/simple’ runs, this time Okapi console records a NullPointerException at the line 48 of the ‘OkapiClient’.
What could be the causes of these situations? Or did I make something wrong with Okapi? I think maybe this have some relationship with ‘Vert.x’.

//============!!!=============================!!!================================
The vertx project can not be blocked. How to debug my own ‘vert.x module’ on my IDE? And how did the devlopers of Okapi do this?
//============!!!=============================!!!===============================

pic1 and pic 2: while excuting the ‘runsimple.sh’ ,during ‘Checking that it works’, Okapi records thread blocked

1

2

pic3 : I wonder why this happened, so I called ‘9132/simple’ directly

It is obviously both module have been deployed successfully, simple-vertx module runs well and be able to make a call to hello-vertx. I think the trouble maybe during the call between simple-vertx and hello-vertx.

I can see we have a problem. Looking into it. Filed it as https://issues.folio.org/browse/OKAPI-322

I have not reproduced the exact same problem, but something close to it. I started Okapi with-Dokapiurl=some.wrong.address and that causes simple to fail with Hello failed with java.nio.channels.UnresolvedAddressException.

Your stack trace and vert.x timeouts seem to indicate that your problem happens in the name resolution too, but that it takes a very long time to resolve the name, and vert.x gives up. What happens if you start everything up, and then try the command curl http://liucxPC:9130 on your machine. Okapi should say “Missing tenant”, and it should not take many milliseconds to do so. If that works, try the same on the docker image for simple. First get the docker id with docker ps, then run the command inside that docker with docker exec
` docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3a2acc237b39 folio-simple-module “java -jar module.jar” 14 minutes ago Up 14 minutes 0.0.0.0:9132->8080/tcp lucid_noether
db684cbce82d folio-hello-module “java -jar module.jar” 14 minutes ago Up 14 minutes 0.0.0.0:9131->8080/tcp zealous_wilson

docker exec 3a2acc237b39 curl -s http://liucxPC:9130
`

That too should say “Missing tenant”, and do so within milliseconds.

If any of the curl commands take several seconds, there is a problem with your name resolution.

I tryed with cmd: docker exec container-id curl -s http://liucxPC:9130. And yes, It did take a long time. Then I tryed running okapi with : java -Dokapiurl=“http://192.168.2.49:9130” -jar okapi-core/target/okapi-core-far.jar, which in the okapiurl param I configured it directly to be my IP address. This time ,there is no name resolution problem anymore and the simple module works well. It’s obvious that you’re right, problem is the name resolution.

After that I configured okapiurl as ‘localhost’, I got a ’ Connection refused: localhost/127.0.0.1:9130 ’ message, which just as your commitment at the ‘issue:OKAPI-322’.

But I have not find out the reason why it can not resolve my HOSTNAME:‘liucxPC’.
Maybe it has some relationship with OS configurations.
I’ll send more informations about this problem.

My PC’s OS is Ubuntu16.04 LTS

Basically, there are two ways Linux resolves host names. It looks in /etc/hosts, and then it makes a DNS lookup. I guess your hostname is in your /etc/hosts on your own box, but not in the docker image where the module runs. I would expect that if you type host -v liucxPC on your workstation, it will take some time too. That command ignores the /etc/hosts, and makes a DNS lookup. The -v makes it show which domains it tries to find the name in.

For now I recommend you keep using your IP address, and/or try to sort out your network configuration with someone on your network. There is very little more I can from this distance.