setup
client (192.168.5.101)
node1 (192.168.5.111)
node2 (192.168.5.112)
sequoia 2.10.9
group communication using appia (TCP TOKEN Channel)
jdk1.5.0_12(1.5.0_12-b04)
PostgreSQL 8.2.4
CentOS release 4.4
switched 100mbps connection
controller.sh modification
JVM_OPTIONS="-Djava.net.preferIPv4Stack=true
-Dsun.net.client.defaultConnectTimeout=1000
-Dsun.net.client.defaultReadTimeout=1000 -Xms1024m
-Xmx1024m ${JVM_OPTIONS}"
controller.xml
<SEQUOIA-CONTROLLER>
<Controller ipAddress="192.168.5.111" port="25322">
<Report hideSensitiveData="true"
generateOnShutdown="true" generateOnFatal="true"
enableFileLogging="true" />
<JmxSettings>
<RmiJmxAdaptor port="1090"/>
</JmxSettings>
<VirtualDatabase configFile="vdb.xml"
virtualDatabaseName="vdb" autoEnableBackends="false"/>
</Controller>
</SEQUOIA-CONTROLLER>
vdb.xml
<SEQUOIA>
<VirtualDatabase name="vdb">
<Distribution
hederaPropertiesFile="/hedera_appia.properties"
clientFailoverTimeout="30000">
<MessageTimeouts/>
</Distribution>
<Backup>
<Backuper backuperName="pgdumpbin"
className="org.continuent.sequoia.controller.backup.backupers.PostgreSQLBinaryBackuper"
options="dumpServer=192.168.5.111"/>
<Backuper backuperName="pgdumpplain"
className="org.continuent.sequoia.controller.backup.backupers.PostgreSQLPlainTextBackuper"
options="dumpServer=192.168.5.111"/>
</Backup>
<AuthenticationManager>
<Admin>
<User username="admin" password=""/>
</Admin>
<VirtualUsers>
<VirtualLogin vLogin="postgres"
vPassword="postgres"/>
</VirtualUsers>
</AuthenticationManager>
<DatabaseBackend name="pgtest1"
driver="org.postgresql.Driver"
url="jdbc:postgresql://192.168.5.111:5432/sq"
connectionTestStatement="select now()">
<DatabaseSchema dynamicPrecision="table"/>
<ConnectionManager vLogin="postgres"
rLogin="postgres" rPassword="postgres">
<VariablePoolConnectionManager
initPoolSize="20" minPoolSize="5" maxPoolSize="0"
idleTimeout="180" waitTimeout="0"/>
</ConnectionManager>
</DatabaseBackend>
<RequestManager>
<RequestScheduler>
<RAIDb-1Scheduler level="passThrough"/>
</RequestScheduler>
<LoadBalancer>
<RAIDb-1>
<WaitForCompletion policy="all"/>
<RAIDb-1-LeastPendingRequestsFirst/>
</RAIDb-1>
</LoadBalancer>
<RecoveryLog driver="org.hsqldb.jdbcDriver"
url="jdbc:hsqldb:file:/opt/sequoia-2.10.9-bin/recoveryLog/vdb/recoveryLog;shutdown=true"
login="sa" password="">
<RecoveryLogTable/>
<CheckpointTable/>
<BackendTable/>
<DumpTable/>
</RecoveryLog>
</RequestManager>
</VirtualDatabase>
</SEQUOIA>
(node2 uses the same set of files, with the ip and
backend names changed to 192.168.5.111 and pgtest2,
respectively
our test was to insert a few records. some of our
tables have bytea columns where we store binary data
(not BLOB). we started by storing a small file (600k)
into the database.
(the code to insert the file)
PreparedStatement ps =
dbConnection.prepareStatement("INSERT INTO party
(party_id, enabled, sign_cert, encrypt_cert, version)
VALUES (?, true, ?, ?, ?)");
ps.setString(1, partyId);
ps.setBytes(2, cert);
ps.setBytes(3, cert);
ps.setString(4, "3.2");
ps.executeUpdate();
so it is actually > 1mb when we look at the data that
is stored (2 bytea columns)
we started by inserting 10 records. everything was ok.
then when we tried 500 it always stops at around
200-220 records.
the end of log for node1 contains:
19:14:09,357 INFO controller.RequestManager.vdb All
activity is now resumed for vdb
19:25:46,421 WARN
virtualdatabase.VirtualDatabaseWorkerThread.vdb Client
(login:postgres,host:192.168.5.101 closed connection
with server)
19:32:15,891 INFO continuent.hedera.gms
Member(address=/192.168.5.112:42402,
uid=192.168.5.112:42402) failed in Group(gid=vdb)
19:32:16,909 WARN controller.virtualdatabase.vdb
Controller Member(address=/192.168.5.112:42402,
uid=192.168.5.112:42402) has left the cluster.
19:32:16,937 INFO controller.virtualdatabase.vdb 1
requests were waiting responses from
Member(address=/192.168.5.112:42402,
uid=192.168.5.112:42402)
19:32:16,948 WARN controller.RequestManager.vdb 1
controller(s) died during execution of request 159
19:32:16,948 WARN controller.RequestManager.vdb
Controller Member(address=/192.168.5.112:42402,
uid=192.168.5.112:42402) is suspected of failure.
19:32:17,691 INFO controller.requestmanager.cleanup
Waiting 30000ms for client of controller
562949953421312 to failover
19:32:17,911 WARN
virtualdatabase.VirtualDatabaseWorkerThread.vdb Client
(login:postgres,host:192.168.5.101 closed connection
with server)
19:32:47,692 INFO controller.requestmanager.cleanup
Cleanup for controller 562949953421312 failure is
completed.
19:38:09,352 INFO continuent.hedera.gms
Member(address=/192.168.5.112:42402,
uid=192.168.5.112:42402) failed in Group(gid=vdb)
19:38:09,884 INFO controller.virtualdatabase.vdb 0
requests were waiting responses from
Member(address=/192.168.5.112:42402,
uid=192.168.5.112:42402)
19:44:40,217 INFO continuent.hedera.gms
Member(address=/192.168.5.112:42402,
uid=192.168.5.112:42402) failed in Group(gid=vdb)
19:44:40,791 INFO controller.virtualdatabase.vdb 0
requests were waiting responses from
Member(address=/192.168.5.112:42402,
uid=192.168.5.112:42402)
while in node 2:
19:15:06,664 INFO
controller.recoverylog.RecoverThread Database backend
pgtest2 is now enabled
19:30:12,403 WARN
virtualdatabase.VirtualDatabaseWorkerThread.vdb Client
(login:postgres,host:192.168.5.101 closed connection
with server)
19:30:40,717 INFO continuent.hedera.gms
Member(address=/192.168.5.111:35574,
uid=192.168.5.111:35574) failed in Group(gid=vdb)
19:30:41,303 WARN controller.virtualdatabase.vdb
Controller Member(address=/192.168.5.111:35574,
uid=192.168.5.111:35574) has left the cluster.
19:30:41,330 INFO controller.virtualdatabase.vdb 0
requests were waiting responses from
Member(address=/192.168.5.111:35574,
uid=192.168.5.111:35574)
19:30:41,377 INFO controller.requestmanager.cleanup
Waiting 30000ms for client of controller 0 to failover
19:31:11,869 INFO controller.requestmanager.cleanup
Cleanup for controller 0 failure is completed.
19:36:12,261 INFO continuent.hedera.gms
Member(address=/192.168.5.111:35574,
uid=192.168.5.111:35574) failed in Group(gid=vdb)
19:36:12,362 INFO controller.virtualdatabase.vdb 0
requests were waiting responses from
Member(address=/192.168.5.111:35574,
uid=192.168.5.111:35574)
19:42:13,209 INFO continuent.hedera.gms
Member(address=/192.168.5.111:35574,
uid=192.168.5.111:35574) failed in Group(gid=vdb)
19:42:13,293 INFO controller.virtualdatabase.vdb 0
requests were waiting responses from
Member(address=/192.168.5.111:35574,
uid=192.168.5.111:35574)
19:48:43,653 INFO continuent.hedera.gms
Member(address=/192.168.5.111:35574,
uid=192.168.5.111:35574) failed in Group(gid=vdb)
19:48:43,754 INFO controller.virtualdatabase.vdb 0
requests were waiting responses from
Member(address=/192.168.5.111:35574,
uid=192.168.5.111:35574)
the client program stack trace:
org.continuent.sequoia.common.exceptions.driver.DriverSQLException:
Connection lost while executing statementExecuteUpdate
with request 'INSERT INTO party (party_id, enabled,
si...' and automatic reconnect failed
(org.continuent.sequoia.common.exceptions.driver.DriverSQLException:
Connection lost while executing statementExecuteUpdate
with request 'INSERT INTO party (party_id, enabled,
si...' and automatic reconnect failed
(org.continuent.sequoia.common.exceptions.driver.VirtualDatabaseUnavailableException:
Virtual database vdb not found on any of the
controllers))
at
org.continuent.sequoia.driver.Connection.statementExecuteUpdate(Connection.java:2929)
at
org.continuent.sequoia.driver.Statement.executeUpdateWithSkeleton(Statement.java:584)
at
org.continuent.sequoia.driver.PreparedStatement.executeUpdate(PreparedStatement.java:183)
at com.apollo.cluster.test.Ha2.addParty(Ha2.java:91)
at com.apollo.cluster.test.Ha2.main(Ha2.java:50)
Caused by:
org.continuent.sequoia.common.exceptions.driver.DriverSQLException:
Connection lost while executing statementExecuteUpdate
with request 'INSERT INTO party (party_id, enabled,
si...' and automatic reconnect failed
(org.continuent.sequoia.common.exceptions.driver.VirtualDatabaseUnavailableException:
Virtual database vdb not found on any of the
controllers)
at
org.continuent.sequoia.driver.Connection.statementExecuteUpdate(Connection.java:2929)
at
org.continuent.sequoia.driver.Connection.statementExecuteUpdate(Connection.java:2925)
... 4 more
Caused by:
org.continuent.sequoia.common.exceptions.driver.VirtualDatabaseUnavailableException:
Virtual database vdb not found on any of the
controllers
at
org.continuent.sequoia.driver.Driver.getConnectionToNewController(Driver.java:422)
at
org.continuent.sequoia.driver.Connection.reconnect(Connection.java:2599)
at
org.continuent.sequoia.driver.Connection.statementExecuteUpdate(Connection.java:2913)
... 5 more
Error in closing Public Key Realm db connection
org.continuent.sequoia.common.exceptions.driver.VirtualDatabaseUnavailableException:
Virtual database vdb not found on any of the
controllers
at
org.continuent.sequoia.driver.Driver.getConnectionToNewController(Driver.java:422)
at
org.continuent.sequoia.driver.Connection.reconnect(Connection.java:2599)
at
org.continuent.sequoia.driver.Connection.close(Connection.java:546)
at com.apollo.cluster.test.Ha2.close(Ha2.java:75)
at com.apollo.cluster.test.Ha2.main(Ha2.java:58)
but what is weird is when we then rerun the client,
the client would be able to insert records on both
nodes!
when i issue the "show controllers" command, it only
shows the local controller for each machine.
for example in node2:
vdb(admin) > show controllers
vdb is hosted by 1 controller(s):
192.168.5.112:1090
when we tested running the program without inserting
the "large" files, there was no problem, we tried to
insert 2000 records (just the id field for example)
and it was ok. i suspect that the controller chokes
on the large volume of data coming from the other
machine.
could there be a way to fix this?
Christopher Gorge A. Marges
[EMAIL PROTECTED](recommended)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
____________________________________________________________________________________
Shape Yahoo! in your own image. Join our Network Research Panel today!
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
