Hi Martin,
Inserts with Sequoia are very tricky, commands that would work
directly on a postgresql connection often generate errors when run
through the sequoia layer, specifically with auto-incrementing
sequences. This also happens if I you accidentally try to create a
table that already exists and probably under other circumstances as well.
Issues related to sequences have been documented and I definitely do not
recommend the use of sequences with Sequoia. Using the proper JDBC 3 API
calls for auto-generated keys is probably a better way. You can also
modify the regular expressions to catch calls to nextval and setval so
that they get properly broadcast. Queries that generate errors (like
trying to create a table that already exists or violating integrity
constraints) should fail similarly on all backends and should be a
non-issue.
Make sure that if you are using connection sensitive variables outside a
transaction scope, you need to use persistent connections.
Upon execution of a command like such a RAIDb level:1 failure occurs
and produces a stack trace like:
ERROR continuent.hedera.adapters PullPushAdapter: Error while reading
from channel
Org.continuent.appia.core.message.MessageException: Trying to read an
unknown object from message
…
This failure is fine and a work around could be investigated.
No, that failure is not fine and it means that something is broken in
your classpath. Your configuration might not be properly mirrored on all
controllers. You have to be careful that if you are using different
database drivers on different controllers, you might still need to put
them in the classpath of other controllers so that they can deserialize
exceptions if the driver does not do a good job of using standard APIs.
The big issues is that when anything like this happens the connections
are not closed and continue to fillup the maximum connection queue.
After a while in production with maybe just a few bad queries; the
database locks up because no more connections can be processed.
The error message you get above happens at the deserialization at the
group communication level which means that your communication with the
other controller is basically broken and at least one message is lost
which is extremely bad when total order is needed. Depending on what
message has been lost, some queries may wait forever for a response
(unless a timeout is set) or a request might be lost (which is not better).
So not only is some Data not getting inserted into the database but
users eventually lose the ability to read as well!
That can be expected given the kind of error you get. I don't know
what's wrong in your setup but that should not happen.
Is there any way to cope with this issue, or disable the connections
from staying open? Is there a way to do a complete pass through of
commands to the postgresql driver so they execute properly (as we only
use postgres)?
Yes, I did that when I worked for Continuent but the modifications to
the regular expressions only went into the p/cluster product and not in
Sequoia. I am planning to re-design the DatabaseBackend definition to
have specialized implementations (like we have for backupers) but for
now I have not been able to keep up with my new job and Sequoia 4 so I
did not make progress. Also I was waiting for Continuent to release the
test suite for Sequoia so that I could develop faster (it was promised
to be released back in May 08) but it never happened.
I still provide consulting on Sequoia if you need help specifically for
your project. Feel free to contact me.
Thanks for your feedback,
Emmanuel
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [EMAIL PROTECTED]
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
