Migrating to Zookeeper in Linux - assuming you have JAVA_HOME set

David Smith

I am setting up a new install of 16.4.1 on Linux and got to the part where I am supposed to install Zookeeper on the Search server to support SOLR. The instructions are simple enough, but the silly thing wouldn't start. It says it started but it didn't stay started. The process wasn't running. Looking at the log that isn't named log (it's named 'out'), it said it couldn't find "java". Scanning the shell script I could see it had a $JAVA variable assigned to point to the Java instance but I couldn't see where that variable was defined. I figured it was looking for a JAVA_HOME, but I didn't have one defined. Looking further I saw that JAVA_HOME is deprecated after Java 1.6 and we're running 1.8. Analyzing the script further, it appears to be using a sort of properties file named zkEnv.sh. This is where the $JAVA variable is being defined:

if [ "$JAVA_HOME" != "" ]; then
JAVA="$JAVA_HOME/bin/java"
else
JAVA=java
fi

As you can see, it's making some bold assumptions. Now maybe everyone else's Linux setups are preconfigured for Java in this way, but ours is not. Our root user does not have JAVA_HOME preset as an environment variable. And the PATH variable doesn't have any path pointing to a Java executable by default - our Java structure is on a separate storage mount and holds several versions of Java. To resolve this issue I had to modify the zkEnv.sh file to hardcode it to point to the JDK version most appropriate for this application. Once I did that, Zookeeper started successfully.

Based on there being no reference to anyone else complaining about this anywhere, I assume maybe I'm the only one who has ever had this issue and everyone else has their JAVA_HOME env variable set to some JDK 1.6 version. This is just for anyone who might have the bad fortune of finding themselves in my situation and didn't.

nipper

That's pretty funny because SOLR does not support Java 1.6 or 1.7

I hacked it as well. FYI, you will need to write a wrapper to start SOLR as a non-root user.

We went live it 16.4.0 on all 7 of our servers last weekend. Will move to 16.6 when it's release this summer (it will be the one without bundled Java).

David Smith

Well maybe I'm mistaken about the Java version - I was looking around for the definition of that $JAVA variable and I found this in the main build.xml file:

so I made the assumption that the thing is built with java 1.6. I think I may have misread the part about JAVA_HOME being deprecated - I cannot confirm that.

David Smith

By the way - thanks for the head's up about the SOLR wrapper - do the docs tell you how to create it like they did for the OpenDeploy boot_wrap wrapper? It took me an hour to figure out you don't need the OpenDeploy wrapper anymore in 16.4.1. I was scratching my head wondering why the wrapper kept throwing errors before I started reading docs. This is the first version where OD has actually changed in forever. Now I actually have to pay attention during this install. The Livesite install will be really fun. Not at all looking forward to that.

nipper

So you actually read the docs huh ? Will wonders ever cease ?

I noticed the same thing with OD. Pretty sweet implementation, but took me awhile to figure out what was going on.

No, no sample code. In fact there is not a start solr in general, so I used the tomcat start up script. Then I used the OD non-root script.

BTW, the instructions say to create 2 instances, talking to some SOLR people I know, that is right if you are running SOLR on multiple servers. So I only created 1 instance.

From what I can see this is fairly new technology for OT.

David Smith

I have a feeling I will be bugging you when it's time for me to try and get my Search server running...you've been warned.

I swear I want to strangle the Interwoven/OpenText people for not realizing when they throw new technology out there, especially based on their less than stellar past documentation performance, they really should make some kind of effort greater than zero to help their users to make **** work without a monumental amount of struggling. They really could put some decent docs together if they put a little effort into it. It's so pathetic - especially now that they have this monolithic OpenText beast behind them. It's no wonder Adobe is stealing clients left and right even though their product blows.

David Smith

I have a feeling I will be bugging you after I install Search and try to get the Indexer working...You've been warned.

nipper

you know my number. :-)

David Smith

I swear I want to strangle the people at Interwoven/OpenText whenever they introduce new technology, and given their past history of less than stellar documentation, still manage to put zero effort into giving users any useful documentation and insist on making their users struggle to get anything working when they could easily just make a little effort to put some decent docs together to help us out. It's maddening and has been since Interwoven was Interwoven. No wonder Adobe is stealing clients left and right even though their product is ****.

HeatherH

Dave & Andy - we do have some KBs (and adding more as we go along) for Solr implementation. I'd recommend searching "solr teamsite" to get them as they're created, but there is one for creating the services and setting up Solr/ZK with either Linux or Windows, and for memory settings as well.

David Smith

I have had some interactions with OT Support about this. I am going to look at the KB articles (haven't yet), but the fact remains, if you are instituting a brand new framework for one of your main components, and it involves a third party installation wrapped within your own installation process, you really need to beef up your own documentation and get it solid for your customers PRIOR to launching the product. Making your customers search for KB articles regarding base installation instructions is ludicrous. You have a horrible history of documentation failures. Do better.

David Smith

I have had some interactions with OT Support about this. I am going to look at the KB articles (haven't yet), but the fact remains, if you are instituting a brand new framework for one of your main components, and it involves a third party installation wrapped within your own installation process, you really need to beef up your own documentation and get it solid for your customers PRIOR to launching the product. Making your customers search for KB articles regarding base installation instructions for base application is ludicrous. Do better.