[ https://forge.continuent.org/jira/browse/SEQUOIA-282?page=all ]
Stephane Giron resolved SEQUOIA-282:
------------------------------------
Resolution: Fixed
Backported
> Shutdown Virtualdatabase Command Blocks During Multi-Threaded Requests
> ----------------------------------------------------------------------
>
> Key: SEQUOIA-282
> URL: https://forge.continuent.org/jira/browse/SEQUOIA-282
> Project: Sequoia
> Type: Bug
> Components: Core
> Versions: Sequoia 2.6
> Environment: Sequoia from CVS (checkout 13:00 PDT, Jan 19), 2 controllers,
> each with 1 PostgreSQL 8.1.1 backend.
> Reporter: Dylan Hansen
> Assignee: Mathieu Peltier
> Priority: Blocker
> Fix For: Sequoia 2.7
>
>
> I've come across an issue when manually shutting down a virtual database from
> a controller while the cluster is executing requests. The requests hang for
> about 30 seconds or so, the virtual database is shutdown, but then subsequent
> requests lock. I have 2 threads that are executing the following code:
> try
> {
> Class.forName("org.continuent.sequoia.driver.Driver");
> conn = DriverManager.getConnection(URL);
> conn.setAutoCommit(false);
> }
> ...
> int count = 3;
> for (int i = 0; i < count; i++)
> {
> try
> {
> cs = conn.prepareCall("{call myproc(?)}");
> cs.setString(1, "Thread: " + id + ", Count: " + i);
> cs.executeQuery();
> conn.commit();
> }
> ...
> Here is the scenario where I get the delay, and then eventually the locking
> of the requests:
> T1 - conn = DriverManager.getConnection(URL);
> T1 - conn.setAutoCommit(false);
> = Disable Backend On Controller A (currently connected to) =
> = shutdown virtualdatabase on Controller A = <-- WAITS
> T2 - conn = DriverManager.getConnection(URL);
> T2 - conn.setAutoCommit(false);
> T1 - cs.executeQuery() - transaction 1
> T2 - cs.executeQuery() - transaction 1 <-- WAITS
> T1 - conn.commit() - transaction 1 <-- HANG for approx 30 seconds
> T2 - conn.commit() - transaction 1
> = shutdown virtualdatabase completes =
> T1 - cs.executeQuery() - transaction 2 <-- WAITS
> T2 - cs.executeQuery() - transaction 2 <-- WAITS
> Both cs.executeQuery commands are stuck. Here's the output of the log of the
> controller with the running virtua database:
> 15:50:17,165 DEBUG virtualdatabase.VirtualDatabaseWorkerThread.h2st Begin
> command
> 15:50:17,165 DEBUG sequoia.controller.scheduler Begin scheduled - current
> pending writes: 1
> 15:50:17,165 DEBUG sequoia.controller.scheduler Begin scheduled - current
> pending transactions: 2
> 15:50:17,165 DEBUG controller.RequestManager.h2st Begin transaction
> 562949953421315
> 15:50:17,168 DEBUG sequoia.controller.scheduler Begin completed, remaining
> pending writes: 0
> 15:50:17,169 DEBUG virtualdatabase.VirtualDatabaseWorkerThread.h2st
> CallableStatementExecuteQuery command
> 15:50:17,170 DEBUG controller.RequestManager.h2st Logging transaction
> 562949953421315 begin
> 15:50:17,170 DEBUG sequoia.controller.recoverylog Logging request 9
> 15:50:17,170 DEBUG backend.DatabaseBackend.database3 Dynamic schema gathering
> level: table
> 15:50:17,170 DEBUG sequoia.controller.recoverylog INSERT INTO logtable
> VALUES(9,h2st,begin,T,562949953421315,0,0,-1)
> 15:50:17,170 DEBUG backend.DatabaseBackend.database3 Gathering database schema
> 15:50:17,170 DEBUG backend.DatabaseBackend.database3 Fetching schema with
> precision 'table' not including system tables.
> 15:50:17,177 DEBUG backend.DatabaseBackend.database3 Table found: myproctest
> 15:50:17,208 DEBUG backend.DatabaseBackend.database3 Using gathered schema as
> new schema.
> 15:50:17,210 DEBUG controller.RequestManager.h2st Broadcasting request {call
> myproc(?)}/<!%S|Thread: t2, Count:... transaction 562949953421315 to all
> controllers (Member(address=192._._.13/192._._.13:33043,
> uid=h2st)->[Member(address=192._._.12/192._._.12:33468, uid=h2st),
> Member(address=192._._.13/192._._.13:33043, uid=h2st)])
> 15:50:17,210 DEBUG continuent.hedera.adapters Sending message 5 to 2 members.
> 15:50:17,235 DEBUG controller.virtualdatabase.h2st
> handleMessageSingleThreaded (class
> org.continuent.sequoia.controller.virtualdatabase.protocol.DistributedCallableStatementExecuteQuery):
> [EMAIL PROTECTED]
> 15:50:17,235 DEBUG controller.virtualdatabase.h2st 192._._.13:25322:
> Scheduling distributedRequest 562949953421317 from
> Member(address=192._._.13/192._._.13:33043, uid=h2st)
> 15:50:17,235 DEBUG sequoia.controller.scheduler Schedule {call
> myproc(?)}/<!%S|Thread: t2, Count: 1|!%> - Current pending writes: 1
> 15:50:17,236 DEBUG controller.virtualdatabase.h2st handleMessageMultiThreaded
> (class
> org.continuent.sequoia.controller.virtualdatabase.protocol.DistributedCallableStatementExecuteQuery):
> [EMAIL PROTECTED]
> 15:50:17,237 DEBUG controller.virtualdatabase.h2st 192._._.13:25322:
> Executing distributedRequest 562949953421317 from
> Member(address=192._._.13/192._._.13:33043, uid=h2st)
> 15:50:17,237 DEBUG controller.RequestManager.h2st Read Stored Procedure
> (562949953421317) : {call myproc(?)}/<!%S|Thread: t2, Count:...
> 15:50:17,237 DEBUG sequoia.controller.loadbalancer Request 562949953421317
> execute on 1 backends
> 15:50:17,237 DEBUG controller.loadbalancer.RAIDb1 Scheduling request {call
> myproc(?)}/<!%S|Thread: t2, Count: 1|!%> in stored procedure queue
> 15:50:17,238 DEBUG sequoia.controller.loadbalancer Adding task
> CallableStatementExecuteQueryTask for transaction 562949953421315 ({call
> myproc(?)}/<!%S|Thread: t2, Count: 1|!%>) to pending request queue
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://forge.continuent.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
