Recently I started using a really powerful tool. Not so much in the amount of features available but in the way it allows me to be more efficient.

I do my job mainly from a laptop. As most of you will know typing and moving your mousepointer with the mousepad is not what you would call ‘ideal’.
Keeping in mind that my job involves lots of typing, as I’m also a happy coder , RSI is waiting to happen.

Now how does this powerful tool help? As I do my job mainly on my laptop I started carrying a spare keyboard and mouse with my laptop to allow for easier typing and mousing.
That is no longer necessary as I have gotten to know ‘QuickSynergy’. This tool runs on Linux and, lucky me, I am running Ubuntu on my laptop and on my desktop.
I have QuickSynergy installed on both my laptop and on the desktop system, iI have done so by using the Synaptics Package manager.

QuickSynergy is a relatively simple tool. It allows me to use the keyboard and mouse from the ’server’ on the ‘client’.

My desktop system has a keyboard and regular mouse connected. Every morning when I come into the office I start QuickSynergy on the desktop, set it up as host and do the same on my laptop but then in set it up in client mode.
See the screenshots. Left is my desktop, right is the laptop.

When the client and server have connected I just move my mouse beyond the left of the desktop’ screen and the mousepointer appears on my laptop.
Fortunately the focus of the keyboard is also transferred to where the mouse is located. So having the mousepointer on the laptop enables typing on the laptop and having the mousepointer on the desktop enables typing on the desktop.

There is also some basic Clipboard info transfer from client to server and vice versa which is very handy. You cannot drag windows from one machine to the other so copy/pasting information bidirectionally is very useful.

Give it a try, its a great tool!
If its not shipped with your distro, see http://code.google.com/p/quicksynergy/

Sometimes things change within a corporate network. And sometimes these changes also impact a GlassFish domain. How much does relocating a server impact the GlassFish Domain? That depends; When the glassfish installation was performed using proper DNS / hostnames then there should not be very much impact. When the GlassFish configuration itself (like JDBC resources or resource adapters) are also spared of IP-address usages then the impact should be diminished even further.

Unfortunately GlassFish uses some internal components which store the more physical information of the network location of the various GlassFish instances in a domain. This becomes apparent when the GlassFish domain is relocated to another IP-address range or VLAN.

Starting the domain after changing its underlying networkstructure could result in not being able to start domain or server instances within the domain. The logfiles might indicate that a connection to the IMQBroker has not been possible within the last 6000 milliseconds.

An exception like this will also be shown in the logfiles of the failing instance:

The most common cause for this is network problems. Checking the correct DNS lookup and reverse lookup of the DAS and the various nodes containing in stances in the domain will provide more information whether there is a network problem.
If DNS lookup succeeds and the hosts-file of the operating system does not contain any incorrect references then other things might go wrong.

The problem could also lie within a corrupted persistent store of the IMQbroker(s). Looking at the imq log.txt files which are located in the server instance folders (and more specifically in the imq/instances/[full unique instancename]/log folder within the nodeagents folder) one might see message like:

Clearing the persistent store can actually be done by executing the imqbroker daemon using the -reset store parameters. Issue the following command from within the [GLASSFISH-HOME]/imq/bin directory:

Replace the variables between brackets as appropriate! Mind the -name argument which contains a concatenated cluster and instancename!

For example:

After this has been started, stop it and start the server instance which would previously not start. The persistent store for this instance has been cleared so a rendez-vous with the DAS should now work once again.

When you plugin a default ubuntu installation into a network which uses a .local TLD then you can run into a problem.
out-of-the-box the Name Service Switch service has a configuration file which conflicts with this situation.

When you ping a server like for instance myserver.example.local it will not work.
When you ping myserver then you do get replies.

This behaviour is cause by the following line in your /etc/nsswitch.conf file:

nsswitch uses this configuration file to determine how it should lookup information regarding (in this case) hosts.
It will first check the filesystem (/etc/hosts for intance) to do a name resolve. Then it will do a minimal multicast DNS and if still no result is returned then a NOTFOUND will be returned.

Whenever you network is setup in a zeroconf environment (no DNS server present) then the multicast will not happen for .local domains.

To fix this situation you need to move on of the databasenames from the hosts line to the send in line. See the following fixed hosts line in /etc/nsswitch.conf:

Save the file and try to do a ping again. You will now see that it works (if ICMP protocol is not blocked by firewalls ofcourse