HCL Traveler and error 500

Posted on by

HCL Traveler is one of those addons for Domino that just works. If you have a properly configured HTTPS stack, you install it, start it and you’re basically done. From now on, you can connect your mobile devices to your Domino server to read your mail and calendar.

At least, that has always been my experience until very recently. The other day I was sent to a customer to fix their problem with Traveler. They had upgraded their Domino server and Traveler installation from 8.5.3 FP5 to 12.0.1 FP1. Everything worked (Kudos for Domino!) except Traveler. Though on further discussion with the client it became clear that Traveler actually already broke earlier and hadn’t been working for the past 6 years or so.

The problem looked simple enough. If I tried to access https://<domino-url>/traveler in the browser, I would get an error 500. The Traveler logs showed up errors CLFAD0211E and CLFAD0246E. Searching on those returned zip though. Apparently I was looking at a seriously rare error. On the Domino side, everything looked fine. “Tell traveler status” returned a normal status page.

My first approach was to fix the TLS setup as the person who upgraded the server to Domino V12, wasn’t aware of the Certificate Manager. After I had a valid SSL certificate and could open the homepage through HTTPS, I started on Traveler. As there was no history to speak of, I decided to uninstall Traveler, delete all related files and reinstall it. I loaded Traveler, opened the /traveler page in the browser and… error 500. Ouch.

I had noticed already that the server was upgraded in a way I would strongly advise against. They wanted to upgrade both Domino and the Windows version, so they moved the entire Domino program directory to a new (Windows) server and then installed Domino 12.0.1 over the old installation. If you do such an upgrade, the way forward is to move the Domino Data directory or even just the Domino databases you need (or even better, replicate the Domino databases to a new server). Copying over the program directory just copies a lot of legacy stuff, which obscures your installation and could get in the way. In the end, it turned out that indeed this way of upgrading had caused this Traveler problem.

To make a long story short(er), the problem was with garbage from the previous Domino installation left behind in the jvm and osgi directories. I would have preferred at this stage to uninstall Domino, remove the remaining program files (while leaving the data directory and notes.ini file) and reinstall Domino with FP1 and Traveler, but I was there during working hours and wasn’t allowed to stop the server for the amount of time that it would take me to do the above procedure. So instead, I installed Domino 12.0.1 with FP1 and Traveler on a desktop. Copied the jvm and osgi directories to the Domino server in a different path. Stopped the Domino server, moved the old jvm and osgi directory out of the program directory, moved the new ones in and started Domino. That costed me a downtime of just under a minute. When browsing to the /traveler url, I was now greeted with the familiar Traveler page and also for mobile devices, Traveler was working fine.
Lessons learned:

  • If you want to move your Domino server to a new OS, don’t copy along the Domino program directory!
  • If you have an error 500 in Traveler, your jvm and osgi directories should be a suspect

And on a side note, this would never have happened if they used Domino containers…