Hi Guys, I am still having this problem, did this one fall off the
radar? If it's a bug, I'd say it's a pretty serious one, or if it's
configuration, I'd very much appreciate some help, thanks. I'd be happy
to provide my config files if needed...
Don Isenor wrote:
Sorry, forgot to mention, I already tried this with 2.10.9 and the
problem is the same.
Robert Hodges wrote:
Hi Don,
I would recommend trying with Sequoia 2.10 (latest build
2.10.9). The Sequoia 3.0 code base is pretty unstable. There are some
modest changes in VDB definition formats but otherwise the change is
not hard.
For other people who may be listening on the list we
(Continuent, the humble supporters of Sequoia) do not intend to port
any additional features or fixes in to Sequoia 3.0. All production
work for our commercial products is going into Sequoia 2.10.
Cheers, Robert
Robert Hodges, CTO, Continuent, Inc.
Mobile: +1-510-501-3728 Skype: hodgesrm
On Aug 29, 2007, at 4:32 PM, Don Isenor wrote:
Apologies if this is not the proper
channel,
if so please direct me accordingly...
When I test Sequoia with concurrent requests, I (almost always) get
this exception:
java.sql.SQLException: A query with id 0 has already been
scheduled
This is occurring in AbstractScheduler.scheduleReadRequest(), because
there is already an id=0 request in activeReadRequests.
My configuration is: a single JBoss (4.05) talking to a single Sequoia
(3.0 Beta 2) controller with two MySQL (5.0.41) backends.
Poking around in the Sequoia source code, and running it under the
debugger, I notice that "AbstractRequest.id" is not set for many (if
not all) queries. Under light or non-concurrent load this is not a
problem, but with concurrent requests, sooner or later the scheduler is
presented with one of these id=0 requests before it has had time to
remove the previous one. Result: the exception I am seeing.
The problem goes away if I unconditionally set the id in
VirtualDatabaseWorkerThread.setRequestParameters(), i.e., instead of
this:
if (request.isAutoCommit() && transactionStarted)
{
vdb.commit(tid, writeQueryExecutedInThisTransaction,
!queryExecutedInThisTransaction);
return false;
}
else
request.setTransactionId(tid);
request.setId(vdb.getNextRequestId());
return transactionStarted;
do this:
request.setId(vdb.getNextRequestId());
if (request.isAutoCommit() && transactionStarted)
{
vdb.commit(tid, writeQueryExecutedInThisTransaction,
!queryExecutedInThisTransaction);
return false;
}
else
request.setTransactionId(tid);
return transactionStarted;
but this is just a kludge to illustrate my problem and
hopefully point the way to a solution.
Is this a known problem? Or maybe I have configured things incorrectly?
_______________________________________________
Sequoia mailing list
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
|
