nodetool not run when cassandra service is started by java code - service

I started my CassandraDaemon thread not as service in windows using [services.msc] but by the following code.
public static void start() {
if (cassandraDaemon == null) {
cassandraDaemon = new org.apache.cassandra.thrift.CassandraDaemon();
cassandraDaemon.activate();
}
}
The above code starts the cassandra service and I tested it,it works.But nodetool.bat file not run.
When I use the following command nodetool -h IPADDRESS info it produce
Failed to connect to 'IPADDRESS:7199': Connection refused: connect
as reply.
I added following one during init
System.setProperty("cassandra-foreground","true");
System.setProperty("com.sun.management.jmxremote","true");
System.setProperty("com.sun.management.jmxremote.port","7199");
System.setProperty("com.sun.management.jmxremote.authenticate","false");
System.setProperty("com.sun.management.jmxremote.ssl", "false");**
What should i Add in coding by that nodetool can run....
If any one know kindly reply me as I need it very immediately.....

You are setting the JMX port to 7199, then trying to connect to that using nodetool. Problem is nodetool uses the Thrift port, which by default is 9160.

Ive lost a lot of time trying to fix this, today finally did it
Just go to
C:\Program Files\DataStax Community\apache-cassandra\conf
and edit the file cassandra.yaml
Look for: listen localhost and change it for listen x.x.x.x
where x.x.x.x is the IP of the local host machine.
Restart Cassandra Service and be sure Windows firewall allows the connection.
Maybe you want to start with firewall off to check if nodetool is working.

Related

mongodb dump fails with cannot unmarshal DNS message

I am using a mongo db server version MongoDB shell version v4.0.16 installed on a EC2 instance.
I am able to get into the instance using mongo command
mongo mongodb+srv://dxxxxxxx:xxxxxx[][]#cluster0-vxcen.gcp.mongodb.net
MongoDB shell version v4.0.16
connecting to: mongodb://cluster0-shard-00-02-vxcen.gcp.mongodb.net.:27017,cluster0-shard-00-01-vxcen.gcp.mongodb.net.:27017,cluster0-shard-00-00-vxcen.gcp.mongodb.net.:27017/?authSource=admin&gssapiServiceName=mongodb&replicaSet=Cluster0-shard-0&ssl=true
2020-03-05T09:02:45.265+0000 I NETWORK [js] Starting new replica set monitor for Cluster0-shard-0/cluster0-shard-00-02-vxcen.gcp.mongodb.net.:27017,cluster0-shard-00-01-vxcen.gcp.mongodb.net.:27017,cluster0-shard-00-00-vxcen.gcp.mongodb.net.:27017
2020-03-05T09:02:45.604+0000 I NETWORK [ReplicaSetMonitor-TaskExecutor] Successfully connected to cluster0-shard-00-00-vxcen.gcp.mongodb.net.:27017 (1 connections now open to cluster0-shard-00-00-vxcen.gcp.mongodb.net.:27017 with a 5 second timeout)
2020-03-05T09:02:45.607+0000 I NETWORK [js] Successfully connected to cluster0-shard-00-01-vxcen.gcp.mongodb.net.:27017 (1 connections now open to cluster0-shard-00-01-vxcen.gcp.mongodb.net.:27017 with a 5 second timeout)
2020-03-05T09:02:45.707+0000 I NETWORK [js] changing hosts to Cluster0-shard-0/cluster0-shard-00-00-vxcen.gcp.mongodb.net:27017,cluster0-shard-00-01-vxcen.gcp.mongodb.net:27017,cluster0-shard-00-02-vxcen.gcp.mongodb.net:27017 from Cluster0-shard-0/cluster0-shard-00-00-vxcen.gcp.mongodb.net.:27017,cluster0-shard-00-01-vxcen.gcp.mongodb.net.:27017,cluster0-shard-00-02-vxcen.gcp.mongodb.net.:27017
2020-03-05T09:02:46.010+0000 I NETWORK [js] Successfully connected to cluster0-shard-00-00-vxcen.gcp.mongodb.net:27017 (1 connections now open to cluster0-shard-00-00-vxcen.gcp.mongodb.net:27017 with a 5 second timeout)
2020-03-05T09:02:46.028+0000 I NETWORK [ReplicaSetMonitor-TaskExecutor] Successfully connected to cluster0-shard-00-01-vxcen.gcp.mongodb.net:27017 (1 connections now open to cluster0-shard-00-01-vxcen.gcp.mongodb.net:27017 with a 5 second timeout)
2020-03-05T09:02:46.439+0000 I NETWORK [js] Successfully connected to cluster0-shard-00-02-vxcen.gcp.mongodb.net:27017 (1 connections now open to cluster0-shard-00-02-vxcen.gcp.mongodb.net:27017 with a 5 second timeout)
Implicit session: session { "id" : UUID("1c7432d5-e09c-45f8-8d84-d47e4f572cbf") }
MongoDB server version: 4.2.3
WARNING: shell and server versions do not match
Error while trying to show server startup warnings: user is not allowed to do action [getLog] on [admin.]
MongoDB Enterprise Cluster0-shard-0:PRIMARY>
I am trying to connect to a mongo db Atlas to get the database using mongodump
mongodump --uri="mongodb+srv://dxxxxxxx:xxxxxx[][]#cluster0-vxcen.gcp.mongodb.net/xxxxxxxxxx"
I am facing issues with
error parsing command line options: error parsing uri (mongodb+srv://dxxxxxxx:xxxxxx[]#cluster0-vxcen.gcp.mongodb.net/xxxxxxxxxx): lookup cluster0-vxcen.gcp.mongodb.net on 127.0.0.53:53: cannot unmarshal DNS message
This is just a case of incompatible DNS server.
Locate /etc/resolv.conf file and replace the nameserver with 8.8.8.8, and everything should work just fine. If that does not work , try 1.1.1.1.
This issue is simmilar to the one reported here.
The fix for changing resolv.conf as above seems not to persist reboots.
The workaround proposed in the link above is either to use non srv url, or, a simpler way that and as far as I have seen survives reboots as well, is to remove the symlink /etc/resolve.conf and replace it with a static file containing the required DNS server.
Another option, found here
Suggests installing resolvconf (for Ubuntu apt install resolvconf), add the line nameserver 8.8.8.8 to /etc/resolvconf/resolv.conf.d/base, then run sudo resolvconf -u and to be sure service resolvconf restart.
To verify run systemd-resolve --status.
You should see on the first line your DNS server like here:
DNS Servers: 8.8.8.8
DNS Domain: sa-east-1.compute.internal
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
Two solutions that worked for me:
Add nameserver with value 8.8.8.8 or 1.1.1.1 additionally to existing ones in /etc/resolve.conf file
Use connection string in format mongodb://{db}:{pass}#hostname1.mongodb.net,hostname2.mongodb.net,hostname3.mongodb.net/admin?authSource=admin&replicaSet={replicaSet}&readPreference=primary&ssl=true instead of mongodb+srv:// format
To get the formatted connection string, you can use db.getMongo() command on your cluster
In some causes, for example in environment where you can't change resolver you can use old style URL:
client = pymongo.MongoClient("mongodb://<username>:<password>#<cluster>...
After change URL generated by cloud.mongodb.com Atlas
in section Cluster -> Connect -> Choose a connection method -> Python - 3.4 or later
It finally started working.
My setup:
Ubuntu 18.04
Python 2.7.17 / 2.7.12
Pymongo 3.11.1
Google Cloud SDK 319.0.0
In my case, only MongoDB connections went wrong with my DNS server.
However, it worked with Google DNS 8.8.8.8, as suggested above.
The solution for me was to decrease the UDP max packet size (same as Google DNS)
cat /etc/bind/named.conf.options
options {
#...
listen-on { 127.0.0.1; };
allow-recursion { 127.0.0.1; ::1; };
edns-udp-size 512;
max-udp-size 512;
};

How to make a TCP outgoing connection with Docker container?

My Go application makes TLS connections via tls.Dial() to exchange data.
It works fine when run from the host:
But the outgoing connection doesn't seem to work when the app is run from a Docker container. The app hangs indefinitely.
Note 1: Same behavior with using docker run -p $(docker-machine ip):2500:2500 ...
Note 2: VM doesn't have extra port forwarding settings other than the default settings that came with docker-machine's default VM.
Docker image build with Dockerfile:
FROM golang:latest
RUN mkdir -p "$GOPATH/src/path/to/app"
# Install dependencies
RUN go get github.com/path/to/dep
VOLUME "$GOPATH/src/path/to/app"
EXPOSE 2500
WORKDIR "$GOPATH/src/path/to/app"
CMD ["go", "run", "main.go"]
Host is OS X running docker-machine.
Question
How can I make the TCP outgoing connection to work?
You are either using boot2docker or docker-machine (since you are running docker on OSX). If you are using boot2docker, you have to forward the ports on VirtualBox as well as docker, have a look at this blog post:
https://fogstack.wordpress.com/2014/02/09/docker-on-osx-port-forwarding/
If you are using docker-machine, you have to connect to the docker-machine assigned ip, not localhost, have a look at this post:
https://github.com/docker/machine/issues/710
I see now that you are using docker-machine specifically, so the post about docker-machine should answer your question.
Edit: I misunderstood the question. You are trying to make an outgoing connection on a forwarded port. That is not correct. By default docker can make outgoing connections on any port. The port forwarding is for incoming connections only. Please try again without specifying any ports to forward. My suspicion is that you are trying to make an outgoing connection on the incoming (forwarded) port.
I've just had exactly the same problem. Was unable to connect out at all.
Restarted the container, and suddenly outgoing connections worked fine. It's possible that the container survived an update of docker?
Currently using Docker version 18.09.3, build 774a1f4

How do I stop Apache/Tomcat server on localhost://8080?

I keep getting errors when trying to serve files locally. I am using Tomcat on port 8080.
When using Eclipse, I get the following error message:
Several ports (8080, 8009) required by Tomcat v8.0 Server at localhost are already in use. The server may already be running in another process, or a system process may be using the port. To start this server you will need to stop the other process or change the port number(s).
Question
How do I stop the server on port 8080 if I don't know which process started it?
Try to go with a web browser to:
localhost:8080 or 127.0.0.1:8080
and
localhost:8009 or 127.0.0.1:8009
There you could see which service is running on those ports.
Then it will be more simple to understand what you have to stop.
EDIT:
You could use a prompt and the command:
netstat -b
-b it will show the name of the executable running on a port.
For understanding how it works here a good explanation.

Receiving ERR_CONNECTION_REFUSED after Sinatra deployment on Digital Ocean

Having a problem with deployment of a small Sinatra app that works fine locally, and seems like its running on digital ocean, but can't be hit via the domain name. The following is the message I receive:
This webpage is not available
Error code: ERR_CONNECTION_REFUSED
The following is what's displayed on my droplet using rackup -p 80, which to me indicates it should be able to be hit:
Thin web server (v1.6.3 codename Protein Powder)
Maximum connections set to 1024
Listening on localhost:80, CTRL+C to stop
If it makes any difference, I also cannot hit the ip address directly. Anyone encounter similar problems or possibly a solution? The app is on ubuntu uses psql as a database. It would be greatly appreciated. Thanks!
Bind your app on 0.0.0.0 instead of localhost:
ruby your_app.rb -o 0.0.0.0
or
rackup --host 0.0.0.0
In production, you should setup a reverse proxy (eg. using nginx or apache) to bind a domain to your app internal port insteal of opening everything on 0.0.0.0

run a distribution test with jmeter in Vm Centos

I'm trying to run a distribution test for learning purpose and i'm using a Virtual machine Centos 7 as a slave in my Windows 7 ( master running in window 7) but even if i configure the master with the IP of the slave ( VM ), modifying the file jmeter.properties, doesn't work, i try run Jmeter-server in the Centos machine but this problem appears.
Created remote object: UnicastServerRef [liveRef: [endpoint:[127.0.0.1:44341](lo
cal),objID:[4e68a212:14a8564a618:-7fff, 5760053273490727502]]]
Server failed to start: java.rmi.RemoteException: Cannot start. localhost.locald
omain is a loopback address.
An error occurred: Cannot start. localhost.localdomain is a loopback address.
Can somebody give me a direction where look or a explanation how can i do it?
Thanks!
Put the following line in system.properties file: java.rmi.server.hostname=xxx.xxx.xxx.xxx
Alternatively start JMeter providing above property as a command-line argument as:
jmeter (or jmeter-server) -Djava.rmi.server.hostname=xxx.xxx.xxx.xxx
Double check your network configuration, i.e. make sure that your /etc/hosts file contains the following lines:
127.0.0.1 localhost localhost.localdomain
xxx.xxx.xxx.xxx your CentOS machine hostname
In all above cases xxx.xxx.xxx.xxx should be IP address of your CentOS machine and this IP address must be different from 127.0.0.1.
Also make sure that you select "Bridged" networking in your Virtual Machine, machines should be able to reach each other over the network, firewalls should be properly configured to allow communication, etc.
For more information on different JMeter Properties and ways of setting/overriding them see Apache JMeter Properties Customization Guide