jconsole: “Connection Failed: Retry?” #SOLVED #java #jmx

So you wrote a piece of server software and you found out about JMX and the jconsole tool to remotely monitor all sorts of interesting metrics remotely, all without adding a single line of code to your project.

Say you want to run it the simplest way possible with no authentication, the tutorial says that these are the options you need to pass to the remote virtual machine to enable JMX remote monitoring on some port (let’s put 9595 for illustrative purposes).

[bash]
-Dcom.sun.management.jmxremote.port=9595′,
-Dcom.sun.management.jmxremote.ssl=false’,
-Dcom.sun.management.jmxremote.authenticate=false
[/bash]

right?

But when you open your jconsole on your local computer to connect to the remote server…

[bash]
jconsole myserver.com:9696
[/bash]

You get this fucking error no matter what you do.

You’re just missing one more option they must have forgotten to mention in the retard tutorial at oracle.com

(let’s use IP address 72.14.204.147 as the remote server IP)

[bash]
-Dcom.sun.management.jmxremote.port=9595′,
-Dcom.sun.management.jmxremote.ssl=false’,
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=72.14.204.147 #ip of the remote machine, yes the ip, not the name
[/bash]

Voilà

Discussion: Water as a medium of Intercontinental High Speeds Data Transfer

If water can transfer sound (low frequencies) 4 times faster than air, can it do the same for higher frequencies?

could you encode megabits/s at an ideal physical frequency range and transmit it over rivers, seas, or even oceans?

I’m thinking that the Air is probably one of the worst data transmission mediums available, it’s useful to us for mobile communications (cellphones, tv) since we humans in 2010 live above ground, however it’s not very good for transcontinental data transfer, the curvature of the air and weather conditions affect it and we have to use satellite and undersea cables to transfer data when it comes to intercontinental distances.

I wonder if instead of using undersea cables (which can be vandalized), wouldn’t it make sense to send data directly over water in a P2P fashion?

What limitations would exist? Signal Interference, Signal noise, curvature of the earth (how often you’d need to put re-transmission/routing nodes).

The idea would be to have thousands (or actually as least as possible) buoyant computers to route data packets from continent to continents. (submarines can transmit data, so it must be doable)

The decentralization of data transfer would make it more reliable, also there would be no-one owner of this transmission network controlling the price of transmission, all the network stack would be based on open standards.

If there are any physicists reading, I’d love to hear your opinions based on your knowledge of Wave Physics and it’s applications for data transmission over water as medium.

Update: It seems it’s very feasible, I found the following illustration on a patent for a similar idea.

It seems most of the current applications for this idea are for military, submarines and planes. I’m thinking of this but for the internet. There are many countries who are currently not connected to high speed internet backbones, with this technology every coast in the world could potentially have better access to the internet.

Mercurial for Subversion Expats: Merging remote changes. “abort: push creates new remote heads!”


Commit anywhere/anytime with Mercurial

So you have been using subversion for the past few years and now your team has decided to move on to Mercurial for all the benefits. Two or more people are working on the same branch and they’re pushing code to the main copy of the repository before you’re done with your changes.

In the Subversion world, if you tried to commit in this same situation you’d get an error saying that your repository checkout is not up to date, so you’d fix this by doing:

[bash]
$ svn up #gets the latest changes from the repo and it tries to merge all remote changes
$ # … solve any conflicts if they arise.
$ svn ci -m "my commit message" #push your latest changes to the main repo.
[/bash]

In Mercurial it’s a little bit longer

[bash]
$ hg ci -m "my local changes"
$ hg pull #this brings the latest version of the repo, but doesn’t change the state of your files.
$ hg merge #when you’re ready, you merge the changes
[/bash]

If at this point you try to push, you will get the following error
[bash]
$ hg push
pushing to https://user@server.com/company/project
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)
[/bash]

first, ignore the “push -f to force”, they should remove that message and put something like
[bash]
(did you forget to merge and commit?)
[/bash]

After a lot of thinking I was doing something wrong with the merge, I realized that before pushing you have to commit your merge locally as well, makes sense, so the whole sequence should be like this instead:

[bash]
$ hg ci -m "my local changes" #same as ‘hg commit’
$ hg pull #this brings the latest version of the repo, but doesn’t change the state of your files.
$ hg merge #when you’re ready, you merge the changes
$ hg ci -m "merging latest changes from repository"
$ hg push
pushing to https://user@server.com/company/project
searching for changes
http authorization required
realm: Bitbucket.org HTTP
user: gubatron
password:
adding changesets
adding manifests
adding file changes
added 2 changesets with 1 changes to 1 files
bb/acl: gubatron is allowed. accepted payload.
[/bash]

So, yes, its a little more work to merge and commit, but remember that you’re working now on a distributed fashion and you have to think a little bit differently, you gotta merge locally, fix any conflicts if they arise, commit the changes and push them. In exchange you don’t get to deal with lots of .svn folders, no single point of failure (one remote repo that could go down and leave all developers without version control until it’s back up), and super easy branching on a single folder, no need to checkout branches and be writing down revision numbers.

Just remember that pulls don’t change your local changes unless you explicitly ask to do so by invoking hg merge; hg commit, which would be the equivalent (at least I see it like this) to svn up