Which JRE to use with IBM Connections Solr?

I noticed on another deployment of IBM Connections 5.5 which includes Solr (Type Ahead Search) the Admin dashboard reported less information as before. The difference is that I used the JRE with WebSphere.

It seems that the output provided in the dashboard is less when using the JRE with WebSphere. There is no stipulation of which JRE should be used but it seems sensible to install Oracle Java since some of the data is missing. Take a look at the screen shots below.

Oracle JRE

1

IBM JRE

2

Advertisements

Restart script for IBM Connections Apache Solr aka Type Ahead search

I wanted to put together a script to allow me to start, stop and restart Solr so I managed to cobble together the below version which seems to work pretty well. I am sure there are others who will read this that have better *nix scripting skills who may want to improve it.

In this case I am using JRE that comes with WebSphere but you could use Oracle Java.

# vim /etc/init.d/solr

#!/bin/sh
#
# apache
#
# chkconfig: 5 90 10
# description: Restart script for Apache Solr created by Ben.Williams@chooseportal.com
SOLR_DIR=”/opt/IBM/solr/solr-4.7.2/node1″
JAVA_STOP_OPTIONS=”-DSTOP.PORT=8079 -DSTOP.KEY=mysecret -jar start.jar”
JAVA_START_OPTIONS=”-DSTOP.PORT=8079 -DSTOP.KEY=mysecret -Djetty.ssl.clientAuth=true -Dhost=$(hostname –fqdn) -Dcollection.configName=myConf -DzkRun -DnumShards=1 -Dbootstrap_confdir=/opt/IBM/solr/solr-4.7.2/node1/solr/quick-results-collection/conf -Dsolr.solr.home=/opt/IBM/solr/solr-4.7.2/node1/solr -jar start.jar”
#LOG_FILE=”/opt/IBM/solr/solr-4.7.2/node1/logs/solr.log”
JAVA_HOME=”/opt/IBM/WebSphere/AppServer/java/bin/java”
RETVAL=$?
case $1 in
    start)
        echo “Starting Solr”
        cd $SOLR_DIR
        $JAVA_HOME $JAVA_START_OPTIONS >/dev/null 2>&1 &
        ;;
    stop)
        echo “Stopping Solr”
        cd $SOLR_DIR
        $JAVA_HOME $JAVA_STOP_OPTIONS –stop >/dev/null 2>&1 &
        ;;
    restart)
        $0 stop
        sleep 10
        $0 start
        ;;
    *)
        echo “Usage: $0 {start|stop|restart}” >&2
        exit 1
        ;;
esac
exit $RETVAL

# chmod 755 /etc/init.d/solr
# chkconfig –add solr
# chkconfig –level 35 solr on

Here is an Oracle JRE suitable version.

#!/bin/sh
#
# apache
#
# chkconfig: 5 90 10
# description: Restart script for Apache Solr created by Ben.Williams@chooseportal.com
SOLR_DIR=”/opt/IBM/solr/solr-4.7.2/node1″
JAVA_STOP_OPTIONS=”-DSTOP.PORT=8079 -DSTOP.KEY=mysecret -jar start.jar”
JAVA_START_OPTIONS=”-DSTOP.PORT=8079 -DSTOP.KEY=mysecret -Djetty.ssl.clientAuth=true -Dhost=$(hostname –fqdn) -Dcollection.configName=myConf -DzkRun -DnumShards=1 -Dbootstrap_confdir=/opt/IBM/solr/solr-4.7.2/node1/solr/quick-results-collection/conf -Dsolr.solr.home=/opt/IBM/solr/solr-4.7.2/node1/solr -jar start.jar”
JAVA_HOME=”/usr/lib/jvm/jre/bin/java”
RETVAL=$?
case $1 in
    start)
        echo “Starting Solr”
        cd $SOLR_DIR
        $JAVA_HOME $JAVA_START_OPTIONS >/dev/null 2>&1 &
        ;;
    stop)
        echo “Stopping Solr”
        cd $SOLR_DIR
        $JAVA_HOME $JAVA_STOP_OPTIONS –stop >/dev/null 2>&1 &
        ;;
    restart)
        $0 stop
        sleep 10
        $0 start
        ;;
    *)
        echo “Usage: $0 {start|stop|restart}” >&2
        exit 1
        ;;
esac
exit $RETVAL

Update 24/11/16

Please replace hostname –fqdn with your actual server hostname otherwise your hostname will be replaced with “-fqdn”

Rich Content widget widget stops working due to mix matched SSL protocols

For an IBM Connections 5.5 customer I found that periodically the Rich Content widget (RTE) stops working showing “The page could not be created due to an error” like the image below.

1

The following exceptions are seen in the SystemOut.log and access.log.

[6/21/16 10:10:34:889 CEST] 00000282 ConnectContro W org.springframework.social.connect.web.ConnectController oauth2Callback Exception while handling OAuth2 callback (I/O error on POST request for “https://connections.acme.com/oauth2/endpoint/connectionsProvider/token”:Server returned wrong cipher suite for session; nested exception is javax.net.ssl.SSLProtocolException: Server returned wrong cipher suite for session). Redirecting to IBMConnections connection status page.
[6/21/16 10:10:34:904 CEST] 00001811 ServletWrappe E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0014E: Uncaught service() exception root cause rteServlet: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘scopedTarget.ibmConnections’ defined in com.ibm.lconn.rte.config.SocialConfig: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.social.connections.api.IBMConnections]: Factory method ‘ibmConnections’ threw exception; nested exception is java.lang.IndexOutOfBoundsException
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:982)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:861)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:575)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)

46.58.58.130 – – [21/Jun/2016:10:10:34 +0200] “GET /oauth2/endpoint/connectionsProvider/authorize?client_id=conn-rte&response_type=code&acls=true&callback_uri=https%253A%252F%252Fconnections.acme.com%252Fconnections%252Frte%252Fcommunity%252F8e3190fe-fb3e-4ebd-83d4-1f319e7a5522%252Fentry&_oauth_client_auto_authorize=true&scope=Connections HTTP/1.1” 302 –
46.58.104.37 – – [21/Jun/2016:10:10:34 +0200] “GET /dm/atom/people/feed?self=true&format=json&anonymousCheck=true&membershipTimestamp=1461057779000&dojo.preventCache=1466496635731 HTTP/1.1” 200 404
46.58.58.130 – – [21/Jun/2016:10:10:34 +0200] “GET /connections/rte/connect?code=iK97VSiDgGJzorfylyBpEVt3OJ800r HTTP/1.1” 202 104
46.58.104.37 – – [21/Jun/2016:10:10:34 +0200] “GET /connections/rte/community/8e3190fe-fb3e-4ebd-83d4-1f319e7a5522/entry?acls=true HTTP/1.1” 500 615

There was an interesting thread in the Socially Integrated blog which was along the same lines but not a match so I raised a PMR. The ever dependable Dave McCarthy and Kevin Holohan shed some light on what was happening.

“According to a chat I had with L3, this is a bug in the JVM. If a connection is established with TLS 1.0 to a specific host (like say host1.ibm.com) then it caches the TLS cipher that was exchanged with the host so that it doesn’t have to do negotiate again. Now if another app in JVM tries to establish connections with TLS 1.2 to the same host (host1.ibm.com) the cached info is reused. This causes the problem. Host1.ibm.com is requesting TLS 1.2 but cached connection in JVM is at TLS 1.0”

It seems that the RTE application is not honouring the protocol as detailed in the Quality of protection (QoP) settings in the ISC and is trying to connect using TLS 1.2. This has triggered Technote How to Force IBM Connections 5.5 CR1 to Use TLSv1.2.

Furthermore I was made aware of LO89164 which is an update to RTE so that it utilises the intraservice URLs for each of the connections components and is be able to direct the HTTP requests issued by RTE component to the appropriate internal endpoint URLs, as referenced in the LCC.xml.

LO89164 can only be applied to CR01 which the customer is not running yet. LO89164 will be included in CR02. This ifix is only available from IBM by logging a PMR, it’s not on Fix Central.

When I am given a maintenance window I need to do the following:

  1. WAS FP8
  2. CR01
  3. Apply LO89164 (included in 5.5 CR2)
  4. Change QoP settings

This should cover off this problem. CR01 also includes other identified bugs in RTE which I won’t go into here but it’s worth applying….