I have GC functions which I develop and test locally by using Cloud Pub/Sub emulator.
I want to be able to check from within Go code if Cloud Pub/Sub emulator is up and running. If not, I would like to inform a developer that he/she should start emulator before he/she execute code locally.
When the emulator starts I noticed a line
INFO: Server started, listening on 8085
Maybe I can check if port is available or similar.
I guess you have used this command:
gcloud beta emulators pubsub start
And you got the following output:
[pubsub] This is the Google Pub/Sub fake.
[pubsub] Implementation may be incomplete or differ from the real system.
[pubsub]
[pubsub] INFO: IAM integration is disabled. IAM policy methods and ACL checks are not supported
[pubsub]
[pubsub] INFO: Applied Java 7 long hostname workaround.
[pubsub]
[pubsub] INFO: Server started, listening on 8085
If you take a look at the second INFO message you'll notice that the process name will be JAVA. Now you can run this command:
sudo lsof -i -P -n
Getting all the listening ports and applications, the output should be something like this:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
XXXX
XXXX
java XXX XXX XX IPv4 XXX 0t0 TCP 127.0.0.1:8085 (LISTEN)
Alternatively you can modify the previous command to show only what is happening on the desired port:
sudo lsof -i -P -n | grep 8085
Related
Problem: I am unable to publish uplink measures to TTN(The Things Network,MQTT Broker) through MQTT Publisher Client. Follow these steps...
Installed Eclipse Mosquitto providers a CLI to subscribe and to publish
messages.
Start Mosquitto Service.
start mosquitto service
MQTT command to publish uplink measure:
mosquitto_pub -h eu.thethings.network -p 1883 -u applicationid-P ttn-account-v2.xXXXXXXXXXXXXXXXXXXXXXXXXX -t applicationid/devices/deviceid/up -m '{"port":1,"payload_raw":"AWcAuw=="}' -d
MQTT command to subscribe uplink measure:
mosquitto_sub -h eu.thethings.network -p 1883 -u applicationid -P ttn-account-v2.x2Q20I2hDo1XXXXXXXXXXXXXXXXX -t applicationid/devices/deviceid/up
Double check that you can really reach to this 52.169.76.255 host and 1883 port using telnet tool or equivalent, for example I cannot connect to this server.
According to WHOIS information the IP address belongs to Microsoft corporation so my expectation is that you're trying to test an application which is deployed in Azure cloud infrastructure. I would recommend checking if port 1883 is open for incoming connections and if not you will need to configure the VM and open the port (you might also need to do the same in the OS firewall)
Once you will be able to establish the connection using telnet (or equivalent) JMeter should also be able to connect and send/receive the messages.
Just in case check out Testing the MQTT Messaging Broker for IoT - A Guide
I have created a Google compute instance with Container-optimized-OS image.
I have configured the firewall to allow http and https.
I am using the docker image with spring boot application which connects to cloudsql. When I use run command on compute engine instance ssh, i.e. (docker run --rm name), the spring boot app is started successfully.
When I try to access the webservices through compute engine instance external ip, it is not working.
I went through a different question, and found that I should try using the sudo wget http://localhost command on the instance cli first and if it is good then everything should be good. But I am getting a connection refused message on 127.0.0.1:80.
I also tried the command to open port from Container optimized OS, I.E.
sudo iptables -w -A INPUT -p tcp --dport 80 -j ACCEPT , nothing is working.
The default port for Spring Boot is 8080 and not 80.
Run this command inside the instance container to see what ports are in LISTENING state:
sudo netstat -tulpn | grep LISTEN
You can redirect port 80 to port 8080 with this command:
sudo iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
Note: This iptables command only redirects port 80 to 8080 on network interfaces. This has no effect for localhost or 127.0.0.1.
For Google Compute Engine instances you do not need to enable ports using iptables. This is done via Google VPC firewall rules. You can use both but make sure you understand exactly what you are configuring and the side effects.
Note: Your Spring Boot application needs to listen on 0.0.0.0 and not 127.0.0.1 nor localhost. The last two are internal only addresses. 0.0.0.0 means listen on all network interfaces.
Note: Do not use sudo in front of wget. This is not necessary.
First, confirm what port your springboot application uses - if it's 8080 or 80. This depends on what you have configured inside application.properties file. This port is referred to as ContainerPort in below steps.
Execute docker run <image-name>:<tag>. This will run the image and show container logs on the console. If there is something wrong with your spring-boot app, the logs will show that and the container will shutdown. Press Ctrl+C to stop the container and return to shell.
If there is no error in step 1 run docker run -d -p<HostPort>:<ContainerPort> <image-name>:<tag>. Here HostPort is any free port in your GCP host VM and ContainerPort is the port used by your spring boot application within the container. Option d starts your container in detached mode.
Run docker ps and make sure that the container started in step 2 is running. It may not run if there is an error - for example if the HostPort you specified is already in use.
If step 3 shows that the container is running, execute curl http://localhost:<HostPort>/<End-Point-Path>. Here End-Point-Path is a valid path to a working endpoint within the container. If the endpoint is correct you should see expected result from the spring-boot app in the console.
Navigate to Google Cloud Console -> VPC network -> Firewall rules and add a firewall rule to open HostPort on your GCP VM.
Access your endpoint via the VM's external IP with URL - http://<VM-External-IP>:<HostPort>/<End-Point-Path>
Unless there is an application issue with your spring-boot app these steps should get you going.
I was able to build the correct solution by your help (John Hanley and Cyac).
I am combining both solutions in order to help the next person facing this.
As told by John, by default Spring boot uses port 8080, not 80 and as specified by Cyac you need to specify the port as 80 explicitly in application.properties file using
server.port=80
Make sure you expose the port 80 in docker image
On GCP Contaier optimized OS make sure you have allowed traffic for HTTP and HTTPs
Run command:
sudo iptables -w -A INPUT -p tcp --dport 80 -j ACCEPT
Run docker using:
docker run -p 80:80 SPRING_IMAGE.
Where SPRING_IMAGE is the name of the docker image with spring boot build.
Test by using curl http://localhost/ENDPOINT_NAME , e.g. http://localhost/shops/all
I'm running an example solace broker (using the command here) and trying to connect to it from a web browser. I've succeeded in connecting to it using the client libraries, but I understand it should be possible to connect to it using the paho-mqtt library. Unfortunately, all the examples are for the Java library, which uses a different connection API. Does anyone have an example that literally just called "mqtt.Connect" and gets a successful return code?
Solace totally supports the Eclipse Paho MQTT libs... the problem is that quick-and-dirty getting started on that page (new location: https://solace.com/software/getting-started/) doesn't expose all the ports you need. Unfortunately, Docker needs the exposed (published) ports defined at create time (unless you're on a Linux machine and you created your Docker container with "host" networking). So if you're on Docker for Windows or Docker for Mac, you'll have to recreate your container.
The default MQTT non-TLS WebSockets port is 8000. (There's a whole bunch more: https://docs.solace.com/Configuring-and-Managing/SW-Broker-Specific-Config/SW-Broker-Configuration-Defaults.htm). So your container create command will be something like:
docker run -d -p 8000:8000 -p 8080:8080 -p 55555:55555 -p:80:80 --shm-size=2g --env username_admin_globalaccesslevel=admin --env username_admin_password=admin --name=solacePSPlusStandard solace/solace-pubsub-standard
That should allow your Paho JS API to connect! Maybe add 1883 (MQTT over TCP) and 9000 (REST messaging) ports as well, just in case.
I have just started to use Vue CLI 3 for a project and it looks like I am not terminating a development session correctly. Like the docs suggests I start a development session with:
npm run serve
Which gives me the port to work on:
App running at:
- Local: http://localhost:8087/
- Network: http://192.168.0.100:8087/
When I'm done working on my project I hit Ctrl-Z and I have my command line back. Yay!
But this leaves something still listening on the port:
lsof -i TCP:8087
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
node 58122 jannie 14u IPv4 0xc7ce0b7d644a357d 0t0 TCP *:8087 (LISTEN)
How can I terminate the development server gracefully so that it frees the port when I am done?
Try using Ctrl-C instead. It allows the application to gracefully shut down.
Are there difference in the way how Tomcat8 is bind to windows network socket whe is started from console (by startup.bat) of if is started as a windows service? I am not able to connect to application web if Tomcat is started as a windows service. See netstat if started from console:
C:\Program Files\Apache Software Foundation\apache-tomcat-8.0.0-RC10\bin>netstat -abnop tcp | grep -i -B2 8089
[java.exe]**
TCP 0.0.0.0:8089 0.0.0.0:0 LISTENING 6016
See netstat if started as a service (notice different name of listening process):
C:\Program Files\Apache Software Foundation\apache-tomcat-8.0.0-RC10\bin>netstat -abnop tcp | grep -i -B2 8089
[tomcat8.exe]**
TCP 0.0.0.0:8089 0.0.0.0:0 LISTENING 2856
Windows service was created by documentation: 'service.bat Install'.
"Image path" of service is: "c:\Program Files\Apache Software Foundation\apache-tomcat-8.0.0-RC10\bin\tomcat8.exe" //RS//Tomcat8
What am I doing wrong?
1st thing you should do:
Check your Windows Firewall :)
When you say "different name of listening process", are you talking about the PID? Have you tried to use "ProcessExplorer" (http://technet.microsoft.com/en-us/sysinternals/bb896653) to check the discrepancies between the Java processes that are created when you start the Tomcat instance?
When you mouse over the java process you can see the JVM arguments assigned for that JVM instance, also, when you right-click the java.exe process you can check its properties, on the "TCP/IP" tab you can check if your Tomcat is listening on the right port. Try to start Tomcat using both approaches and take a closer look with ProcessExplorer, that should help you identify any misconfiguration.