Trying to run the 1 Master 2 Slave with 3 Sentinel setup on localhost (Windows), using redis-3.0.5 64 bit, as described here :
https://github.com/ServiceStack/redis-config.git
All instances come up fine and seems to be communication till I test the failover using the command :
redis-cli -p 6380 DEBUG sleep 30
this commands returns after 30 seconds during which the Master becomes unavailable and my Java app, using Spring-Data-Redis with Jedis client, goes into a connection retry mode.
There are no log messages on the console or log file for any of the Redis or Sentinel instances. No indcation of any of the 2 slaves being promoted to master.
The command "SENTINEL get-master-addr-by-name mymaster" shows the same Master IP and Port all through the 30 seconds of sleep and after.
Am I missing something ?
Related
Running JMeter to Master & Slave machines, Slave is showing the script is started & finished, but at master showing "Waiting for possible Shutdown/StopTestNow/HeapDump/ThreadDump message on port 4445", for this at master JMeter script execution not ended, so report and result not generated.
Though this script only contains a HTTP Request with a single thread, for execution it only needs few seconds. I waited for couple of hours, but not got the result.
How can i solve this problem?
for both Master & Slave machines I configured:
install jdk1.8.0_271 & jmeter5.3
on "jmeter.properties" i added : server_port=4000, client.rmi.localport=4000, server.rmi.port=4000, server.rmi.localport=4000
on "user.properties" i added : server.rmi.port=9999, server.rmi.localport=4000
Though this script only contains a HTTP Request with a single thread, for execution it only needs few seconds. - you're running it with 100 threads and 500 seconds ramp-up so it will run for 8 minutes at least (plus time required for the last user to execute the last iteration of the sampler)
The fact that the slave cannot report the test finished event and the results back to the master means that the slave cannot properly communicate with the master
Assuming all above you need to open 2 ports in the slave, i.e.
4000 for the SERVER_PORT
5000 for the server.rmi.localport
and run your slave as jmeter-server -Dserver.rmi.localport=5000 -Dserver_port=4000 -Jclient.rmi.localport=4000
master should be executed as jmeter -Jclient.rmi.localport=4000
All the aforementioned ports must be opened in the firewall.
More information:
Remote hosts and RMI configuration
Using a different port
JMeter Distributed Testing with Docker
Bamboo-jmeter task: Should time gap there before starting the jmeter master/slave. We have created bamboo task (SSH task1-with slave host, SSHtask2-with 2nd slave host, SSH task3-with master host and run commands). When first time the the task getting an error remote engine is not able to configured whereas able to telnet the hosts, also jmeter-server is already started.
However when disable SSHtask1 and task2 for the 2nd time run, it is able to run successfully and getting results also.
Should jmeter master start after 1/2 minutes of server started? Please suggest
Able to overcome the problem by adding sleep time of 120 seconds after running the jmeter-server before starting the jmeter master.
Previous night I was tinkering with Elixir running code on my both machines at home, but when I woke up, I asked myself Can I actually do the same using heroku run command?
I think theoretically it should be entirely possible if setup properly. Obviously heroku run iex --sname name executes and gives me access to shell (without functioning backspace which is irritating) but i haven't accessed my app yet.
Each time I executed the command it gave me different machine. I guess it's how Heroku achieve sandbox. I also was trying to find a way to determine address of my app's machine but haven't got any luck yet.
Can I actually connect with the dyno running the code to evaluate expressions on it like you would do iex -S mix phoenix.server locally ?
Unfortunately it's not possible.
To interconnect Erlang VM nodes you'd need EPMD port (4369) to be open.
Heroku doesn't allow opening custom ports so it's not possible.
In case You'd want to establish a connection between your Phoenix server and Elixir node You'd have to:
Two nodes on the same machine:
Start Phoenix using iex --name phoenix#127.0.0.1 -S mix phoenix.server
Start iex --name other_node#127.0.0.1
Establish a connection using Node.ping from other_node:
iex(other_node#127.0.0.1)1> Node.ping(:'phoenix#127.0.0.1')
(should return :pong not :pang)
Two nodes on different machines
Start Phoenix using some external address
iex --name phoenix#195.20.2.2 --cookie someword -S mix phoenix.server
Start second node
iex --name other_node#195.20.2.10 --cookie someword
Establish a connection using Node.ping from other_node:
iex(other_node#195.20.2.10)1> Node.ping(:'phoenix#195.20.2.2')
(should return :pong not :pang)
Both nodes should contact each other on the addresses they usually see each other on the network. (Full external IP when different networks, 192.168.X.X when in the same local network, 127.0.0.1 when on the same machine)
If they're on different machines they also must have set the same cookie value, because by default it takes automatically generated cookie in your home directory. You can check it out by running:
cat ~/.erlang.cookie
What's last you've got to make sure that your EPMD port 4369 is open, because Erlang VM uses it for internode data exchange.
As a sidenote if you will leave it open make sure to make your cookie as private as possible, because if someone knows it, he can have absolute power over your machine.
When you execute heroku run it will start a new one-off dyno which is a temporary instance that is deprovisioned when you finish the heroku run session. This dyno is not a web dyno and cannot receive inbound HTTP requests through Heroku's routing layer.
From the docs:
One-off dynos can never receive HTTP traffic, since the routers only route traffic to dynos named web.N.
https://devcenter.heroku.com/articles/one-off-dynos#formation-dynos-vs-one-off-dynos
If you want your phoenix application to receive HTTP requests you will have to set it up to run on a web dyno.
It has been a while since you've asked the question, but someone might find this answer valuable, though.
As of 2021 Heroku allows forwarding multiple ports, which allows to remsh into a running ErlangVM node. It depends on how you deploy your application, but in general, you will need to:
Give your node a name and a cookie (i.e. --name "myapp#127.0.0.1" --cookie "secret")
Tell exactly which port a node should bind to, so you know which pot to forward (i.e. --erl "-kernel inet_dist_listen_min 9000 -kernel inet_dist_listen_max 9000")
Forward EPMD and Node ports by running heroku ps:forward 9001:4369,9000
Remsh into your node: ERL_EPMD_PORT=9001 iex --cookie "secret" --name console#127.0.0.1 --remsh "myapp#127.0.0.1"
Eventually you should start your server with something like this (if you are still using Mix tool): MIX_ENV=prod elixir --name "myapp#127.0.0.1" --cookie "secret" --erl "-kernel inet_dist_listen_min 9000 -kernel inet_dist_listen_max 9000" -S mix phx.server --no-halt
If you are using Releases, most of the setup has already been done for you by the Elixir team.
To verify that EPMD port has been forwarded correctly, try running epmd -port 9001 -names. The output should be:
epmd: up and running on port 4369 with data:
name myapp#127.0.0.1 at port 9000
You may follow my notes on how I do it for Dockerized releases (there is a bit more hustle): https://paveltyk.medium.com/elixir-remote-shell-to-a-dockerized-release-on-heroku-cc6b1196c6ad
I setup a distributed load testing environment using JMeter in unbundu machines.
->Master: the system running JMeter GUI, control each slave.
->Slave: the system running jmeter-server, receive command from the master and send a request to server under test.
->Target: the web server under test, get request from slaves.
Basic requirements are done:
-The firewalls on the systems are turned off
-All the planned master and Slaves are in the same subnet
-The JMeter server can access the target.
-Same version of JMeter on all the systems (version 2.3.4 ).
I did the following:
1) Tried pinging form master to slave and vice versa through ubundu terminal. its happening ..
2) Added the following to client (master) jmeter.properties:
# Remote hosts and RMI configuration
remote_hosts=192.168.0.139:1099
# RMI port to be used by the server (must start rmiregistry with same port)
server_port=1099
3) Added the following to server (Slave) jmeter.properties:
# On the server(s)
set server_port=1234
start rmiregistry with port 1234
4) Now started the Jmeter engine on Master.
a) Started Jmeter on master machine (GUI)
b) Created test plan--> (added tread group , samplers and required listners)
c) Now start the Slave(s) from the GUI
-click Run at the top
-select Remote start
-select the IP address
But error popup came as :-
"Connection refused to host : 192.168.0.139; nested exception is : java.net.ConnectionException : Connection Refused"
what may be the reason for not connecting with the remote salve (say here : 192.168.0.139)
DO i need to do any more configuration in jmeter.properties file or in any other files (in both slave and master)?
I think you forgot to start the slave in "slave mode".
In command line mode, go to jmeter/bin directory and execute jmeter-server.bat
That will start the slave process and will keeps it listening for commands.
Then you can go forward, loading amd launching the script.
have a look at:
http://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.pdf
Also be aware that:
- the two systems MUST run the same Jmeter version
- the two systems MUST be on the same subnetwork
- the two systems SHOULD be as similar as possible: same OS, same directory tree, etc
- "remote_hosts" only require the address. The port is specified by "server_port" parameter.
I'm using the MsOpenTech version of Redis on a Windows 2008 server. I've installed via the RedisWatcher Service as described here, and this is working fine - the server is responding and data going in and out nicely, running multiple instances etc - so great.
I have one problem though - i'm attempting to use a redis.conf file to set some default configuration; the .conf file being stored in the same directory as redis-server.exe, namely c:\redis\bin
The config changes themselves are straighforward, i'm simply setting timeout to 20 seconds, thus:
timeout 20
but when I run the watcher service, connect to the server via the command line and do config get timeout, it returns 0
I've tried to restart the watcher service after making the updates to config. I've tried passing in the timeout value directly in the watcher.conf file for the service, like
cmdparms --timeout 20
and this doesn't work. I've attempted the same on a second instance, same results.
Interestingly, if I start a second instance of the redis server within the watcher, thus:
{
workingdir c:\redis\inst2
runmode hidden
saveout 1
cmdparms --port 6380
}
this works, respecting the --port argument and kicking off a second instance at port 6380. Although as mentioned above, passing a --timeout parameter or a config file parameter to this instance is not working either.
Setting configuration via the command line works fine, ie, when connected to redis:
config set timeout 20
This sets the timeout as expected, but obviously doesn't persist the setting beyond that session. This being version 2.6 of redis, I don't have access to the config rewrite command, so can't get around it that way.
Any ideas welcome.
In the end the answer was simple. Restarting the RedisWatcher service does not restart the redis-server.exe process.
Manually stopping this process and restarting via the watcher made the config changes be picked up.