Thanx. I got it started now.
I found another discrepancy that I'm not sure about..
In the demo directory (of 2.10.9), any script that specifies an extra
classpath does it with CLASSPATH_XTRA.
But the install guide at
http://sequoia.continuent.org/doc/2.10/sequoia-install-guide.pdf says
it's XTRA_CLASSPATH.
Which is correct?
Thanx,
-Tony
---------------------------
Manager, IT Operations
Format Dynamics, Inc.
303-573-1800x27
[EMAIL PROTECTED]
http://www.formatdynamics.com
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Emmanuel Cecchet
Sent: Wednesday, April 09, 2008 8:39 PM
To: Sequoia general mailing list
Subject: Re: [Sequoia] Controller config problem
Hi Tony,
The options you are trying to use are not part of the Sequoia 2.9 DTD.
The DTD specifies:
<!ELEMENT SecuritySettings (Jar?, Accept?, Block?, SSL?)>
<!ATTLIST SecuritySettings
defaultConnect (true | false) "true"
>
Note that security settings regarding IP address filtering are going to
be dropped in Sequoia 4. You should better use a firewall to efficiently
deal with this filtering.
Don't hesitate to point obsolete docs and config files so that we can
fix them.
Thanks for your feedback,
Emmanuel
I have a new sequoia install..upon starting the controller I get the
following errors.. My config is below. The order of these elements I
got
from the user's guide, and I checked with the
controller-configuration.xml example also, so I'm not sure why it's
not
liking them. Any help is appreciated.
# 17:04:54,668 INFO controller.core.Controller Sequoia controller
(2.10.9)
17:04:54,855 INFO controller.core.Controller Loading configuration
file: /opt/sequoia-2.10.9-bin/config/controller/controller.xml
17:04:55,168 ERROR controller.xml.ControllerParser Xml document has
not
been validated.
17:04:55,169 ERROR controller.xml.ControllerParser Element
"SecuritySettings" does not allow "Shutdown" here.
17:04:55,170 ERROR controller.xml.ControllerParser Element type
"Shutdown" is not declared.
17:04:55,170 ERROR controller.xml.ControllerParser Element type
"Client"
is not declared.
17:04:55,170 ERROR controller.xml.ControllerParser Attribute "allow"
is
not declared for element "Client".
17:04:55,171 ERROR controller.xml.ControllerParser Attribute
"onlyLocalhost" is not declared for element "Client".
17:04:55,171 ERROR controller.xml.ControllerParser Element type
"Console" is not declared.
17:04:55,172 ERROR controller.xml.ControllerParser Attribute "allow"
is
not declared for element "Console".
17:04:55,176 WARN controller.core.Controller Error while analysing
xml
configuration file (org.xml.sax.SAXException: Controller Xml
configuration file is not valid.).
org.xml.sax.SAXException: Controller Xml configuration file is not
valid.
at
org.continuent.sequoia.controller.xml.ControllerParser.readXML(Controlle
rParser.java:174)
at
org.continuent.sequoia.controller.xml.ControllerParser.readXML(Controlle
rParser.java:206)
at
org.continuent.sequoia.controller.core.ControllerConfiguration.setUpByXm
l(ControllerConfiguration.java:277)
at
org.continuent.sequoia.controller.core.ControllerConfiguration.setup(Con
trollerConfiguration.java:327)
at
org.continuent.sequoia.controller.core.ControllerConfiguration.getContro
ller(ControllerConfiguration.java:353)
at
org.continuent.sequoia.controller.core.Controller.main(Controller.java:7
45)
17:04:55,179 ERROR controller.core.Controller Could not load config
file: /opt/sequoia-2.10.9-bin/config/controller/controller.xml
(Controller Xml configuration file is not valid.). Loading minimum
configuration.
org.xml.sax.SAXException: Controller Xml configuration file is not
valid.
at
org.continuent.sequoia.controller.xml.ControllerParser.readXML(Controlle
rParser.java:174)
at
org.continuent.sequoia.controller.xml.ControllerParser.readXML(Controlle
rParser.java:206)
at
org.continuent.sequoia.controller.core.ControllerConfiguration.setUpByXm
l(ControllerConfiguration.java:277)
at
org.continuent.sequoia.controller.core.ControllerConfiguration.setup(Con
trollerConfiguration.java:327)
at
org.continuent.sequoia.controller.core.ControllerConfiguration.getContro
ller(ControllerConfiguration.java:353)
at
org.continuent.sequoia.controller.core.Controller.main(Controller.java:7
45)
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE SEQUOIA-CONTROLLER PUBLIC "-//Continuent//DTD
SEQUOIA-CONTROLLER 2.10.9//EN"
"http://sequoia.continuent.org/dtds/sequoia-controller-2.10.9.dtd";>
<SEQUOIA-CONTROLLER>
<Controller port="25322">
<Report hideSensitiveData="true" generateOnShutdown="true"
generateOnFatal="true" enableFileLogging="true" />
<JmxSettings>
<RmiJmxAdaptor/>
</JmxSettings>
<VirtualDatabase configFile="virtualdatabase-FD-console.xml"
virtualDatabaseName="console" autoEnableBackends="true"/>
<SecuritySettings defaultConnect="false">
<Jar allowAdditionalDriver="true"/>
<Shutdown>
<Client allow="true" onlyLocalhost="true"/>
<Console allow="false"/>
</Shutdown>
<Accept>
<IpAddress value="x.x.x.x"/>
<IpAddress value="x.x.x.x"/>
</Accept>
</SecuritySettings>
</Controller>
</SEQUOIA-CONTROLLER>
-Tony
---------------------------
Manager, IT Operations
Format Dynamics, Inc.
303-573-1800x27
[EMAIL PROTECTED]
http://www.formatdynamics.com
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, April 08, 2008 2:25 PM
To: Sequoia general mailing list
Subject: Re: [Sequoia] Fault tolerance configuration question
Emmanuel Cecchet wrote:
A RecoveryLog is not recommended but mandatory if you want to recover
from failures and add new nodes on-the-fly.
The recovery log can be stored in an embedded database in the
recovery
log or a standalone database. To prevent the controller from being a
single point of failure (SPOF) you need a second controller. Each
controller has its own recovery log, so that the recovery log is not
a
SPOF either.
You will have to define a distributed virtual database to synchronize
activities between controllers and resynchronize recovery logs. More
details in the Sequoia documentation.
I guess I'm still not seeing how the RecoveryLog avoids being point of
failure. I've looked through the three guides (Administration,
Installation, and User) but fail to see where this is clarified.
Right now I have two MySQL servers (let's call them M1 and M2) and a
single Sequoia server (let's call it S1) with a virtual database (V1)
comprised of both MySQL servers.
If I'm understanding correctly for the RecoveryLog to be fault
tolerant
it would need to be pointed to yet another virtual database (V2) which
would need to be on at least two servers. Assuming I put it on M1 and
M2, then when either M1 or M2 fail the RecoveryLog would become
degraded
and need to be recovered just like the original virtual database (V1)
would it not?
If this is covered in the documentation, perhaps someone could point
me
to what I've missed?
Next step ... configuring the group communication! ;-)
I wanted to get a grasp of how to avoid what I perceive as a single
point of failure in the RecoveryLog before proceeding with what seems
to
be a more complex configuration.
