I am running some erlang code on a Mac OSX, and I have this weird issue. My application is a multi node app where I have a single instance of a server that is shared between nodes (global).
The code works perfectly, except for one annoying thing: the different erlang nodes (I am running each node on a different terminal window) can only communicate with each other after ping!
So if on terminalA I am starting the server, and on terminalB I am running
erl>global:registered_names().
terminalB will return an empty list, unless, before starting the server on terminalA, I have ran a ping (from either one of the terminals).
For example, if I do this on either terminals before starting the server:
erl>net_adm:ping("terminalB").
then I start the server and from the second terminal I list the processes:
erl>global:registered_names().
This time I WILL see the registered process from the second terminal.
Is it possible that the mere net_adm:ping call does some kind of work (like DNS resolving or something like that) that allows the communication?
The nodes in a distributed Erlang system are loosely connected. The
first time the name of another node is used, for example if
spawn(Node,M,F,A) or net_adm:ping(Node) is called, a connection
attempt to that node will be made.
I find this in this link: http://www.erlang.org/doc/reference_manual/distributed.html#id85336
I think you should read this article.
Related
I am currently doing this tutorial. When I am following it as described and execute the alice and bob nodes both on the same machine it works as expected: the nodes are connecting and are creating and finalizing blocks. Now I want to get the same done but over the internet and on different machines. So I execute the bootnode on my PC and the other node on my Laptop. I compiled both from the same code and also forwarded the ports in my router. So now I expect the same behavior as when I am running both on my local machine. So when I execute them I see network traffic printed in both consoles but the bob node prints a warning: Bootnode with peer id '12D3KooWEyoppNCUx8Yx66oV9fJnriXwCcXwDDUA2kj6vnc6iDEp' is on a different chain (our genesis: 0xbfbd…3144 theirs: 0x8859…14c4) and they are not connected (Idle 0 peers).
So from the warning I conclude they have not the same genesis blocks which is obviously necessary to run as a blockchain. But from my understanding the joining node should copy the current state of the chain from the bootnode. How can I change bobs part to use alices state of the chain?
Both machines are running rust version 1.50.0
Thanks for your help!
Rust compilations are not deterministic, thus the exact same code for the exact same blockchain compiled on two computers will unfortunately not have the same genesis hash. (Specifically because part of the genesis of that chain is the Wasm Runtime blob, which is compiled non-deterministically with Rust).
You need to create a chainspec file to use for all other nodes. Note that you want to generate this on one computer, and pass the file to other nodes (don't re-generate it, as the genesis code will differ, as you ran into) before you then start other nodes using the correct chainspec and manually specifying boot nodes.
Background:
I have a 128-core server which I would like to use as a build server.
I have a bunch of client machines which work with a not-so-new and not-so-powerful PC. (Can't upgrade! Not in my control.)
What I did:
I followed the distcc documentation.
And installed a virtual machine on the server with exactly the same compiler version, the same distcc version -- basically the same distribution, as on the client-machines.
After configuring the clients and the servers, I can remotely build. I can verify this using the distccmon-text tool. I can see on the server, there are 8 threads started by the distcc daemon and that are awaiting for build-jobs to come. This was good as a first step. You can see the output below to be sure.
Second Step: Since the client machines are dual-core machines while the server offers 128-cores, and not all clients will be compiling at the same time, I wanted to offload as much of the build as possible to the build-server.
Problems:
First Problem: distcc, no matter how I try to configure it, always tries to distribute the build-jobs equally on the client and the server. Even though my configuration file looks as shown below:
# --- /etc/distcc/hosts -----------------------
# See the "Hosts Specification" section of
# "man distcc" for the format of this file.
#
# By default, just test that it works in loopback mode.
# 127.0.0.1
172.24.26.208/8,cpp,lzo
localhost/0
Which as per the distcc documentation should give higher priority to the build-server and lower-priority to the localhost since it comes later in the list. Also, it should give 8 jobs to the build server and 0 jobs to the localhost. But no, that doesn't happen. Upon typing make -j8 what it tries to do is start 4 threads on localhost and 4 on remote. Not good. This you can see from the image below.
Second Problem: What you would also notice is that the pre-processing is being done on the localmachine. For this there is a tool that comes with distcc. It is called the "distcc-pump" or the pump mode and can be used like this.
time pump make CC="distcc gcc" CXX="distcc g++" -j8
Unfortunately, pump mode or not, the pre-processing happens to be happening all on the localhost, as you can see from the above image. Sad.
Note: At no point does the distcc program, with the configurations I listed here, throw any errors nor warnings, neither on the server nor on the clients.
Versions:
gcc 4.4.5
distcc 3.2rc1.2
(Before someone suggests - "upgrade software!", newer versions are most likely not possible for me. Anyways, this version of distcc offers the features that I need. Also, I can upgrade the server virtual-machine but then there would be compiler version mistmatch between clients and the server. The clients I cannot upgrade.)
Any suggestions, feedback on how to improve this setup/(fix the problems) are most welcome.
EDIT : these solutions do not work, I let the answer to avoid someone else to propose again them
Try by
removing the line concerning the localhost in /etc/distcc/hosts c.f. https://superuser.com/questions/568133/force-most-compilation-to-a-remote-host-with-distcc
or may be specifying 127.0.0.1 rather than localhost in /etc/distcc/hosts c.f. an other problem solved with that substitution in https://distcc.github.io/faq.html
distcc actually differentiates between remote and local CPUs. But contrary to your interpretation, in the hosts file the IP address 127.0.0.1 is considered as a remote CPU and a distccd server is expected to be running there. Any number of jobs you define in the hosts file is interpreted only for these server nodes.
According to the man page, "localhost" is interpreted specially. This is what seems to not work for you. An alternative syntax is --localslots=<int>. Have you tested this?
Additionally, distcc runs jobs on the local host (the one where you start the driver program). First, all linking is done there. Second, when you specify a certain parallelism with make -jN, all jobs exceeding the available number of remote jobs are run on your local host, too - in addition to the workload distribution part of distcc. The option --localslots limits these. The man page does not mention localhost explicitly here. And then there are those jobs, which fail on the server and are repeated locally.
For the given 128-core server I would use the number of cores in the hosts file and start only that number of compile jobs:
$ cat ~/.distcc/hosts
172.24.26.208/128,cpp,lzo
$ make -j 128
...
Then I would expect to not see any compile jobs on the local machine.
The man page has some more words regarding recommended job numbers. Search for the section(s) starting with distcc spreads the jobs across both local and remote CPUs.
I am using a utility called Wireless Network Watcher https://www.nirsoft.net/utils/wireless_network_watcher.html on a -windows 10 machine- that captures the devices connected to my network and export these items to a csv file periodiacally.
The app also offers some command-line options to start the app in the background and scan the network and export the items to a file.
But when I get disconnected from my network (and that happens a lot), the scanning process of the app stops and I need to correct this on each disconnect.
I chose to do this by creating a scheduled task that kills the app when disconnection happens and another one to restart it when I get connected again.
But when I do this, I lose the already recorded items on the already running instance of the app (Like devices that were connected and now are not), so I want to use the command-line option to export the items to a file before killing the app.
C:\WNetWatcher.exe /scomma C:\log.csv
So my question is: Is it doable to pass some parameters (/scomma in my example) to an already running instance of an application, and not starting a new one?
Here are the command Line Options available within the app:
I've had RabbitMQ 3.2.1 (Erl OTP 16B02 x64) running on Win 2008R2, one day it started to return nodedown error. I decided to reinstall RabbitMQ, I've removed Rabbit and Erlang enviriment, cleaned db folder in RABBITMQ_BASE, removed all erlang cookies and RABBITMQ_NODENAME / PORT variables. Intalled RabbitMQ 3.5.4 Erlang OTP18 x64 as admin....but still I'm not able to manage service via command promt, it gives me following output:
I've already seen some post on this error (Post1 , Post2 ) but, as I see right now all that they are suggesting is reinstall RabbitMQ and to be careful with Erlang cookies, and I've cleaned system completely after uninstalling previous version. Still, any suggestions appreciated.
Thanks.
UPD
Funny thing - I've noticed that db folder in RABBITMQ_BASE is empty, so it is empty in %USERPROFILE%\AppData\Roaming\RabbitMQ... I thought it must create node structure there on service first start...
It's telling you that it is trying to connect to a node with name 'rabbit', and it is telling you that there is a node running with a name of 'RabbitMQ'.
Presumably 'RabbitMQ' is indeed your RabbitMQ node? Perhaps your new installation changed the name of the node, or maybe you were using a non default node name before that has been partially reset? Or maybe something else... Either way, I know you said you cleaned it, but there's a definite mismatch in the node name being used by your server and the rabbitmqctl client.
See RabbitMQ configuration for details on how to check and change your configuration (for UNIX and Windows), or try telling rabbitmqctl to use a different node name (this is -n on UNIX, not sure on Windows).
We (the RabbitMQ team) already saw this behavior, but couldn't reproduce it so far. What we discovered is that for unknown reasons, the Windows service is installed without its parameter, in particular, the node name (rabbit#<hostname>) is missing and Erlang (or Windows, I don't know) picks the service name as the node name (RabbitMQ#<hostname>).
rabbitmqctl fails to contact this node because it expects rabbit#<hostname> by default. But anyway, the node is not working properly.
The workaround we know is to remove and reinstall the Windows service.
It's the concern about Admin console's performance from Websphere Application Server.
I can login smoothly without any problem, but it's got be very slow on response when doing operations such as showing Node status by clicking "Nodes" under "System administration", showing AppServer status by clicking "Application Servers" under "Servers" etc. However, the funny thing is the problem is more serious on remote node than the local nodes which locate on same box with DmgrNode.
So i suspect it should be the problem with network communication between DmgrNode and remote Node, but i don't know how to fix it.
Anybody got the same issue here??? Or any idea to figure it out? Please do me a favor, please please .......
When the console gets the list of servers to display, it does make mbean calls to all of the servers, and if there is a network problem between the dmgr and the node, this could cause some delay in displaying the server page. The nodes page, however, should not have that issue. What is your topology? How many nodes/servers and how many are local/remote?
How can you tell the problem is more serious on the remote nodes than the local nodes?
Are other console operations slower, or only ones that display status? Do you have the same problem with wsadmin commands? The console issues a queryNames to search for the server mbeans. Does the following wsadmin command run much more slowly on the remote node than the local node? If so, how much more slowly?
print AdminControl.queryNames('WebSphere:type=Server,node=myNode')
Replace myNode with either the local or remote node name.
I assume you are using IE to fire up the console. Fire the console from Chrome and see if it helps.