CCS and ports/firewall

Question

Trying to us RMI to synchronise caches - mainly because the online docs (login required) say its easier to set-up!

My understanding is that CCS requires port 1099 to be open in firewalls to allow Brokers to subscribe and receive invalidation messages.

Despite doing this though, we still see connection errors on our Brokers.

It now appears that port 1099 is simply the RMI lookup port, after which a random port is negotiated and used to listen on.

This unpredictability of ports seems to make RMI a poor choice if you have to work with firewalls - I'd have to ask for ports > 1024 to be opened?

Is the only option to switch to JMS?

Cheers

Answer 1

Unfortunately, you will have to indeed open up all ports > 1024 if you want to keep using RMI in order to have reliable communication for CCS.

If that's not an option, I would recommend to switch to JMS. Yes, its more work to setup, but you also get a lot more functionality and it works through firewalls as well. Julian Wraith wrote a nice guide to setup Apache MQ and use that as JMS provider for the CCS.

Answer 2

In my opinion JMS is more robust and much more scalable than the CCS. I explained why in this blog: http://blog.trivident.com/2012/09/tridion-and-jms-removing-another-spof/.

Also, see http://blog.trivident.com/2012/09/jms-the-nitty-gritty/ for additional configuration tips.

Answer 3

This article explains it pretty well: http://www.netcluesoft.com/rmi-through-a-firewall.html.

Port 1099 is indeed used only as the initial listening port, and then another (somewhat) random port is used for the actual notifications.

You can force Tridion to use a specific port by using the following code in a Java Listener (if using J2EE)

package com.sdl.tridion.extension.cacheFilter;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
 * Servlet Filter implementation class InitializeCachePort
 */

public class InitializeCachePort implements ServletContextListener {
  Logger log = LoggerFactory.getLogger(InitializeCachePort.class);

  @Override
  public void contextDestroyed(ServletContextEvent arg0) {
  // TODO Auto-generated method stub
  }

  @Override
  public void contextInitialized(ServletContextEvent arg0) {
    // TODO Auto-generated method stub
    int listenerPort = 1051;
    com.tridion.util.TridionRMISocketFactory.setRMIChannelListener(listenerPort);
    log.debug("Initialized Cache Channel Service port: " + listenerPort);
  }
}

This was supposed to be configurable, but was found to be a defect (to be fixed in 2013 SP1). I expect this to work with .NET too, but you'd have to call the Com.Tridion.Util.TridionRMISocketFactory juggernet proxy - should work, but not exactly on the supported side...

UPDATE

Just tried setting this on a new global.asax, and it seems to do the trick for .NET:

<%@ Application Language="C#" %>

<script runat="server">

  void Application_Start(object sender, EventArgs e) 
  {
      // Code that runs on application startup
      Com.Tridion.Util.TridionRMISocketFactory.SetRMIChannelListener(1066);
  }
// remainder of global.asax ommitted

To monitor connections and ports used I've set the CCS logback.xml as set in Frank's example on Tridion World and every time a broker connects you get a log message stating

ListenerRegistry - addListener() Proxy[RemoteCacheListener,RemoteObjectInvocationHandler[UnicastRef [liveRef: [endpoint:10.0.0.213:1066,objID:[-52d91cb8:140e4e0b6d0:-7ffe, 7434567443393203683]]]]] currently 1 registered listeners

Text in bold shows IP + Port used by the connecting broker.