On 13-mrt-2007, at 18:01, Leander Koornneef wrote:
On 12-mrt-2007, at 13:27, Jeff Mesnil (JIRA) wrote:
[ https://forge.continuent.org/jira/browse/SEQUOIA-925?
page=comments#action_13791 ]
Jeff Mesnil commented on SEQUOIA-925:
-------------------------------------
I observed this behavior with the console on JDK 6 only.
I think it has to do with the XML packages bundled by default with
Java 6 (compared to Java 1.4 or 1.5)
As you said, it has no consequences but it very annoying.
I'll try to find a workaround
Hmm, I just checked the docs and they state:
Sequoia requires that the following additional software be
installed on controller nodes:
* Java Software Development Kit (Sun 1.4.2)
I have always assumed that this is a minimum requirement.
I.e.: JDK 1.4 or higher are required/supported. Is this
assumption correct, or should I actually downgrade to 1.4.2?
Hmm, we've been seeing all kinds of weird behavior and/or bugs
in Sequoia in combination with JDK 1.6, The problems appear to
be mostly XML related, although this is based on my subjective
observations. At one point during failover testing, I ran into a
situation where it was impossible to re-add a controller to a RAIDb-1
cluster, because Sequoia thought that the vdb config files on
the two controllers were different, which was positively not the
case, because the config files had not changed since I removed
the controller from the cluster:
========================
2007-03-15 00:13:12,928 ERROR controller.xml.DatabasesParser The
virtual database sequoiadb could not be added to the controller
(because of Error while joining group sequoiadb
(org.continuent.sequoia.common.
exceptions.ControllerException: Virtual database configuration is not
compatible with other controller settings.))
java.lang.Exception: Error while joining group sequoiadb
(org.continuent.sequoia.common.exceptions.ControllerException:
Virtual database configuration is not compatible with other
controller settings.)
at
org.continuent.sequoia.controller.virtualdatabase.DistributedVirtualData
base.joinGroup(DistributedVirtualDatabase.java:629)
at
org.continuent.sequoia.controller.xml.DatabasesParser.endElement
(DatabasesParser.java:646)
at org.apache.crimson.parser.Parser2.maybeElement
(Parser2.java:1528)
at org.apache.crimson.parser.Parser2.content(Parser2.java:1779)
at org.apache.crimson.parser.Parser2.maybeElement
(Parser2.java:1507)
at org.apache.crimson.parser.Parser2.parseInternal
(Parser2.java:500)
at org.apache.crimson.parser.Parser2.parse(Parser2.java:305)
at org.apache.crimson.parser.XMLReaderImpl.parse
(XMLReaderImpl.java:442)
at
org.continuent.sequoia.controller.xml.DatabasesParser.readXML
(DatabasesParser.java:270)
at
org.continuent.sequoia.controller.xml.DatabasesParser.readXML
(DatabasesParser.java:319)
at
org.continuent.sequoia.controller.core.Controller.addVirtualDatabases
(Controller.java:220)
at
org.continuent.sequoia.controller.core.Controller.loadXmlConfiguration
(Controller.java:553)
at
org.continuent.sequoia.controller.core.ControllerConfiguration.setUpVirt
ualDatabase(ControllerConfiguration.java:372)
at
org.continuent.sequoia.controller.xml.ControllerParser.configureVirtualD
atabase(ControllerParser.java:564)
at
org.continuent.sequoia.controller.xml.ControllerParser.startElement
(ControllerParser.java:308)
at org.apache.crimson.parser.Parser2.maybeElement
(Parser2.java:1488)
at org.apache.crimson.parser.Parser2.content(Parser2.java:1779)
at org.apache.crimson.parser.Parser2.maybeElement
(Parser2.java:1507)
at org.apache.crimson.parser.Parser2.content(Parser2.java:1779)
at org.apache.crimson.parser.Parser2.maybeElement
(Parser2.java:1507)
at org.apache.crimson.parser.Parser2.parseInternal
(Parser2.java:500)
at org.apache.crimson.parser.Parser2.parse(Parser2.java:305)
at org.apache.crimson.parser.XMLReaderImpl.parse
(XMLReaderImpl.java:442)
at
org.continuent.sequoia.controller.xml.ControllerParser.readXML
(ControllerParser.java:121)
at
org.continuent.sequoia.controller.xml.ControllerParser.readXML
(ControllerParser.java:171)
at
org.continuent.sequoia.controller.xml.ControllerParser.readXML
(ControllerParser.java:200)
at
org.continuent.sequoia.controller.core.ControllerConfiguration.setUpByXm
l(ControllerConfiguration.java:232)
at
org.continuent.sequoia.controller.core.ControllerConfiguration.setup
(ControllerConfiguration.java:288)
at
org.continuent.sequoia.controller.core.ControllerConfiguration.getContro
ller(ControllerConfiguration.java:314)
at org.continuent.sequoia.controller.core.Controller.main
(Controller.java:752)
Caused by:
org.continuent.sequoia.common.exceptions.ControllerException: Virtual
database configuration is not compatible with other controller settings.
at
org.continuent.sequoia.common.exceptions.SequoiaException.fillInStackTra
ce(SequoiaException.java:103)
at java.lang.Throwable.<init>(Throwable.java:196)
at java.lang.Exception.<init>(Exception.java:41)
at
org.continuent.sequoia.common.exceptions.SequoiaException.<init>
(SequoiaException.java:57)
at
org.continuent.sequoia.common.exceptions.ControllerException.<init>
(ControllerException.java:51)
at
org.continuent.sequoia.controller.virtualdatabase.DistributedVirtualData
base.joinGroup(DistributedVirtualDatabase.java:574)
... 29 more
========================
Also, I had criticial issues while restoring dumps to a backend,
because Sequoia was unable to drop the database first:
========================
2007-03-14 23:38:52,062 DEBUG
backup.backupers.PostgreSQLBinaryBackuper Restoring database
'sequoiadb' on host '10.0.30.50:5432'
2007-03-14 23:38:52,062 DEBUG
backup.backupers.PostgreSQLBinaryBackuper Dropping database 'sequoiadb'
2007-03-14 23:38:52,084 INFO backup.backupers.NativeCommandExec
Starting execution of "dropdb -h 10.0.30.50 -p 5432 -U dbuser
sequoiadb"
2007-03-14 23:38:52,086 DEBUG
backup.backupers.NativeCommandOutputThread Starting
NativeCommandOutputThread: Thread-6
2007-03-14 23:38:52,089 DEBUG
backup.backupers.NativeCommandOutputThread Starting
NativeCommandOutputThread: Thread-7
2007-03-14 23:38:52,100 DEBUG
backup.backupers.NativeCommandOutputThread Terminating
NativeCommandOutputThread: Thread[Thread-6,5,RMI Runtime]
2007-03-14 23:38:52,100 DEBUG
backup.backupers.NativeCommandOutputThread Thread-7: dropdb: database
removal failed: ERROR: database "sequoiadb" is being accessed by
other users
2007-03-14 23:38:52,100 DEBUG
backup.backupers.NativeCommandOutputThread Terminating
NativeCommandOutputThread: Thread[Thread-7,5,RMI Runtime]
2007-03-14 23:38:52,100 INFO backup.backupers.NativeCommandExec
Command "dropdb -h 10.0.30.50 -p 5432 -U dbuser sequoiadb" logged 1
errors and terminated with exitcode 1
2007-03-14 23:38:52,100 WARN backup.backupers.NativeCommandExec
Native command failed with error count=-1
2007-03-14 23:38:52,101 INFO backup.backupers.NativeCommandExec
Process output (stdout):
2007-03-14 23:38:52,101 INFO backup.backupers.NativeCommandExec
Process output (stderr):
2007-03-14 23:38:52,101 WARN
backup.backupers.PostgreSQLBinaryBackuper Unable to drop drop
database prior to restore
2007-03-14 23:38:52,101 DEBUG
backup.backupers.PostgreSQLBinaryBackuper Re-creating 'sequoiadb'
2007-03-14 23:38:52,115 INFO backup.backupers.NativeCommandExec
Starting execution of "createdb -h 10.0.30.50 -p 5432 -U dbuser --
encoding=UTF8 sequoiadb"
2007-03-14 23:38:52,118 DEBUG
backup.backupers.NativeCommandOutputThread Starting
NativeCommandOutputThread: Thread-8
2007-03-14 23:38:52,118 DEBUG
backup.backupers.NativeCommandOutputThread Starting
NativeCommandOutputThread: Thread-9
2007-03-14 23:38:52,120 DEBUG
backup.backupers.NativeCommandOutputThread Thread-9: createdb:
database creation failed: ERROR: database "sequoiadb" already exists
2007-03-14 23:38:52,120 DEBUG
backup.backupers.NativeCommandOutputThread Terminating
NativeCommandOutputThread: Thread[Thread-9,5,RMI Runtime]
2007-03-14 23:38:52,121 DEBUG
backup.backupers.NativeCommandOutputThread Terminating
NativeCommandOutputThread: Thread[Thread-8,5,RMI Runtime]
2007-03-14 23:38:52,122 INFO backup.backupers.NativeCommandExec
Command "createdb -h 10.0.30.50 -p 5432 -U dbuser --encoding=UTF8
sequoiadb" logged 1 errors and terminated with exitcode 1
2007-03-14 23:38:52,122 WARN backup.backupers.NativeCommandExec
Native command failed with error count=-1
2007-03-14 23:38:52,122 INFO backup.backupers.NativeCommandExec
Process output (stdout):
2007-03-14 23:38:52,122 INFO backup.backupers.NativeCommandExec
Process output (stderr):
2007-03-14 23:38:52,124 ERROR
backup.backupers.PostgreSQLBinaryBackuper Error while performing backup
2007-03-14 23:38:52,128 ERROR controller.RequestManager.sequoiadb
Recovery could not complete
========================
As you can see, the backend database cannot be dropped because
there are client connections to it, but these connections are from
Sequoia. However, I could not find a way to prevent Sequoia from
starting connections to the database. I was able to cirumvent this by
killing the postgresql processes from the command line, but then the
restore of the recovery log would fail after restoring the SQL dump.
Basically, we had been running around in circles like this for days,
where solving one issue introduced another and seeing unpredictable
and erratic behavior until we switched to JDK 1.5, after which all these
issues basically went away. I would like to ask this question again: is
JDK 1.6 even supported for Sequoia? If not, then _please_ add this
information to the website and documentation, with a big fat warning
sign next to it, so other users will not have to experience the madness
we did...
Leander
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
