We have two Grails applications that we have installed on one of our EC2
boxes, both running under the same Tomcat instance. The applications make
use of a search client with data set to false. They both need to talk to
the same cluster. The idea was that we would just install these two
applications on the same box for QA purposes, but it doesn't appear that
the two applications play well together within the cluster. The first
application that is deployed works fine, the second one throws a
MasterNodeNotDiscovered exception. I noticed this recently when trying to
do parallel deployments as well (Something we were able to do around
version 0.16.x when we were testing parallel deployments). Is there a way
to get many client nodes to work within the same cluster on the same
machine?
Two clients on the same machine will work well. Note though, if oyu start
two node clients, the first will use port 9300, and the second will use
port 9301, so maybe you don't have it open?
Also, when creating the ndoe client, mark it as node.client set to true (or
simply call client(true) on the NodeBuilder). Just setting it to non data
node means is might still be elected to be a master.
On Wed, Mar 28, 2012 at 6:16 PM, danpolites dpolites@gmail.com wrote:
We have two Grails applications that we have installed on one of our EC2
boxes, both running under the same Tomcat instance. The applications make
use of a search client with data set to false. They both need to talk to
the same cluster. The idea was that we would just install these two
applications on the same box for QA purposes, but it doesn't appear that
the two applications play well together within the cluster. The first
application that is deployed works fine, the second one throws a
MasterNodeNotDiscovered exception. I noticed this recently when trying to
do parallel deployments as well (Something we were able to do around
version 0.16.x when we were testing parallel deployments). Is there a way
to get many client nodes to work within the same cluster on the same
machine?
You nailed it. We only had 9300 opened on our security group. We had a
range of 9300-9400 in the past when we were testing parallel deployments,
which is why it worked then. Thanks!