Blog

Recently ran into an interesting situation working with the current release of the WebCenter Sites JSK (12.2.1.0) that I felt was worth noting. While most aspects of the JSK and development environment are packed away into tidy shell scripts ( start, stop, cleanup, etc.), using the CatalogMover utility would often fail when trying to perform a catalog import.

Using CatalogMover to perform an element import is a common step in many set-ups, from installing GSF, to populating a fresh development environment with existing elements.

Attempting to use the CatalogMover out of the box resulted in several errors:

Immediately noticeable is that the CatalogMover application interface would freeze and be unable to gracefully recover from whatever exception had bubbled up.

Next, a follow-up check of the WebCenter Sites log (sites.log) wll not show any additional information since CatalogMover is being executed from a shell prompt. 

Taking a look at the terminal output we note the following exceptions: 

java.net.SocketException: Can't assign requested address

…

Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError

…

MulticastRMICacheManagerPeerProvider: 

…

Error starting heartbeat. 

Error was: Can't assign requested address (MulticastRMICacheManagerPeerProvider.java, line 98)

…

net.sf.ehcache.CacheException

at net.sf.ehcache.distribution.MulticastRMICacheManagerPeerProvider.init(MulticastRMICacheManagerPeerProvider.java:99)

Cobbling together information from the stack trace it can be generally determine that there is a piece that is not correctly assigning a requested address when initializing Ehcache using multicast. 

It turns out that the cause of this import breaking behavior is from a call for java.net.NetworkInterface.getDefault() on a Macbook/OSX and executing on java version 1.8.0_101. The call for the default network interface from OSX is returning an IPv6 address. 

An IPv6 address looks like this: 2001:0db8:85a3:0000:0000:8a2e:0370:7334 - it represent 128 bits, represented by eight groups of four hexadecimal digits.

The Ehcache initialization is looking for and expecting IPv6’s predecessor - the classic IPv4 address. IPv4 looks like this: 169.254.0.0

The fix, to allow CatalogMover to continue with element import operations, is to set a flag  (preferIPv4Stack) when starting the JVM and set the flag to true.

The snippet to include is:

-Djava.net.preferIPv4Stack=true

To set this CatalogMover start-up configuration we will modify the catalogmover.sh file to execute while including this setting. The updated line of the script, which executes CatalogMover will now be:

$JAVA_HOME/bin/java -Dsites.config=../template -Djava.net.preferIPv4Stack=true -Dorg.owasp.esapi.resources=../template/config -classpath $CLASSPATH COM.FutureTense.Apps.CatalogMover

This resolves the error and the element imports will continue without issue.