Archive for November, 2010

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

Sunday, November 21st, 2010

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).

-Dcom.sun.management.jmxremote.port=9595',
-Dcom.sun.management.jmxremote.ssl=false',
-Dcom.sun.management.jmxremote.authenticate=false

right?

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

jconsole myserver.com:9696

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)

-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

Voilà

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

Sunday, November 21st, 2010

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!”

Sunday, November 14th, 2010


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:

$ 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.

In Mercurial it’s a little bit longer

$ 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

If at this point you try to push, you will get the following error

$ 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)

first, ignore the “push -f to force”, they should remove that message and put something like

(did you forget to merge and commit?)

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:

$ 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.

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




  • Categories

  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • July 2012
  • June 2012
  • May 2012
  • April 2012
  • March 2012
  • February 2012
  • January 2012
  • December 2011
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • August 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • October 2009
  • September 2009
  • July 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • April 2006
  • March 2006
  • February 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005
  • April 2005
  • March 2005
  • February 2005
  • January 2005
  • December 2004
  • November 2004
  • October 2004