4

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

2

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.

| improve this answer | |
3

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.

| improve this answer | |
  • Read your article Q, very interesting - right now the IT guys appear to be up for opening ports > 1024 but good to know about JMS as an alternative. I was slightly confused though, you mention JMS can work over http on port 80 but then say ActiveMQ defaults to 61616? – Neil Sep 3 '13 at 17:00
  • On reading it back I see that this part of the post was a bit confusing. What I meant to say was that JMS can run on any port (including 80) but it defaults to 61616. And more importantly: it runs on a single, fixed port. I updated my post to clarify. – Quirijn Sep 5 '13 at 10:04
2

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.

| improve this answer | |
  • This is a .NET implementation Nuno, how would introduce a class that called the Com.Tridion.Util.TridionRMISocketFactory juggernet proxy? Are you saying I can roll my own extended CCS? – Neil Sep 3 '13 at 17:02
  • This needs to run on application start - and only needs to be done once - so whatever would be the .NET equivalent of a java listener (global.asax?). If you reference Tridion.ContentDelivery you'll see a bunch of classes that start with Com.Tridion.*. You should never use those... except maybe in this case... – Nuno Linhares Sep 3 '13 at 17:23
  • Works with global.asax, will update with sample. – Nuno Linhares Sep 3 '13 at 17:31
  • I see. And if I'm using a single Tridion CD and TRIDION_HOME with several WCF services, does just one of them need to set this Com.Tridion.Util.TridionRMISocketFactory value or would they all need to do it? – Neil Sep 4 '13 at 7:41
  • The Cache Channel Service only sends cache invalidation message, it's not the actual cache. Actual cache is "inside" the JVM that runs the Tridion core, so only the applications actually running Tridion need access to the CCS – Nuno Linhares Sep 4 '13 at 12:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.