Hi,
It seems that there are a couple of issues:
We use auto commit normally, but libmysequoia doesn't like it (gives an
error 'Operation not allowed after ResultSet closed'), so we ran without
auto commit, but didn't perform manual commits...
Alos, the dbh is reused; about the only time a dbh is terminated is when
a program exits. (This is especially true in a mod_perl environment,
where a dbh is only released on exit of Apache).
Unfortunately we're out of time for our research project, so there's not
a lot we can do to test new settings/tweaks.
What we found is that Sequoia has a tendency to stop a backend (crash)
on trivial things like a typing error in an sql statement.
Combined with the trouble of performing a dump/restore whenever a
backend looses its state (not a quick job for a multiple GB database),
it isn't the solution for us (at least not at the moment).
We also had a lot of problems getting Appia to work correctly, but
that's probably for another forum?
We're willing to fill in bug reports for our issues if you like.
Although there is a lot of documentation, it's still a bit of a hit &
miss affair to get things up and running, especially if you want to
combine Sequoia, Appia and libmysequoia. I could have done with an
idiot's guide for that :-)
Cheers,
Jan-willem
Robert Hodges wrote:
Hi Jan-Willem,
It seems as if you must be leaving open a transaction. This being Perl,
I would look for a lost connection somewhere.
Meanwhile, we introduced timeouts for transactions and persistent
connections recently to avoid problems with applications leaving open
transactions that prevent setting checkpoints. It's a common problem
that can leave you really stuck with no other choice than to kill the
controller. The timeout values are in the DTD but not very
transparently documented--here are the relevant entries:
<!ATTLIST RAIDb-1Scheduler
level (passThrough) #REQUIRED
waitForSuspendedTransactionsTimeout CDATA "300000"
waitForPersistentConnectionsTimeout CDATA "300000"
>
You can suppress the behavior by setting the values to 0. One could
argue that 0 should be the default but we have found that in practice
this arises commonly enough in production deployments that it seemed
better to put in an explicit value.
Cheers,
Robert
Robert Hodges, CTO, Continuent, Inc.
Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Mobile: +1-510-501-3728 Skype: hodgesrm
On Jul 24, 2007, at 1:43 PM, Emmanuel Cecchet wrote:
Jan-willem,
When everything is up and running, I start a test script that will do
a lot of create/read/update/delete queries (on one table). The test
script is in Perl (like everything that uses the database here).
While this script is running I start the console on one backend, and
issue a disable backend.
The backend will then start its shutdown cycle, and complain about
open transactions, and that it will wait for 300 seconds for them to
finish.
When you disable a backend it will wait for currently open
transactions to complete but not start new transactions. Are you sure
that your Perl script commits or rollbacks every transaction and does
not leave open transactions?
I am not sure why this 300 seconds timeout was introduced, IMHO this
is a bad idea, this should only be an option and definitely not the
default.
The transactions will not finish in that time, and then the backend
crashes.
Do you have any transaction that takes more than 5 minutes to complete?
Thanks for your feedback,
Emmanuel
--
Emmanuel Cecchet
Chief Scientific Officer, Continuent
Blog: http://emanux.blogspot.com/
Open source: http://www.continuent.org
Corporate: http://www.continuent.com
Skype: emmanuel_cecchet
Cell: +33 687 342 685
_______________________________________________
Sequoia mailing list
[email protected]
<mailto:[email protected]>
https://forge.continuent.org/mailman/listinfo/sequoia
------------------------------------------------------------------------
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
