-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Emmanuel,
>> 1) Is it possible to configure the ports for file-transfers (tansfer >> dump, restrore log, ...) >> > Yes, you can configure the transfer dump port number. Check > https://forge.continuent.org/jira/browse/SEQUOIA-830 > Restore log just uses the group communication so you should not have to > set anything specific. Thanks, thats what I've looking for. :) >> 2) We are using Squirell_SQL for manual database queries and checks. >> When we connect to the sequoia controller with it, no tabes are listed >> for the database anymore. But we can execute any sql statement >> sucessfully. Is there a problem with the metadata/schema browsing in >> sequoia, or does it need configuring? >> > I don't know exactly which JDBC call Squirrel is trying to do to fetch > the schema. We just forward the call 'as is' to the underlying database. > Sometimes the underlying driver expects null to fetch the entire schema > and sometimes it expect '%' for all tables. What happens if you connect > Squirrel directly to your database backend? Do you notice the same > problem or is it Sequoia specific? > It is Sequoia specific, but I'm not exactly sure which statement Squirrel is issuing to the driver, but I get an exception that getSuperTable(...) is an unsupported operation in the postgres driver. This statement must fail also when connecting directly to the database. I think there are two possibilities: 1) Sequoia does not forward the exception/response back 'as is' to the client 2) Squirrel does look at the jdbc-url/driver metadata and do a special handling for some databases which it does not for Sequoia. Since I've also had this for MySQL (not only Postgres) I would opt for option 2 and guess Squirrel does some db-specific lookup. Thanks Markus > Thanks for your feedback, > Emmanuel >> Thanks again for all your help >> Markus Wolf >> >> Linas Virbalas schrieb: >> >>> Hello Markus, Emmanuel, >>> >>> I’m sorry if I’m creating a new thread with this message - I have just >>> subscribed to this list and am replying with a new message. >>> >>> Markus, I would recommend you trying the attached JGroups over TCP >>> protocol stack configuration. As it is built on a reliable TCP protocol >>> which does fragmentation by itself your problem should be solved. You >>> will need to replace the current JGroups configuration file (total.xml?) >>> and restart the controllers for this change to work. >>> >>> Best luck! >>> Linas >>> >>> On 9/18/08 7:44 PM, "Robert Hodges" <[EMAIL PROTECTED]> >>> wrote: >>> >>> ------ Forwarded Message >>> *From: *Markus Wolf <[EMAIL PROTECTED]> >>> *Reply-To: *Sequoia general mailing list >>> <[EMAIL PROTECTED]> >>> *Date: *Thu, 18 Sep 2008 09:34:25 -0700 >>> *To: *Sequoia general mailing list >>> <[EMAIL PROTECTED]> >>> *Conversation: *[Sequoia] Sequoia Transaction Problem >>> *Subject: *Re: [Sequoia] Sequoia Transaction Problem >>> >>> Hi Emmanuel, >>> >>> >>>> You may have a problem in your group communication setup if the >>>> fragmentation layer is not working in JGroups. >>>> >>> Where could the problem in the fragmentation layer? We just use the >>> default sequencer jgroups file shipped with sequoia. >>> Can you point me to a good documentation source, since we are not firm >>> with jgroups. >>> >>> >>>> You may also have to check your recovery log configuration to make >>>> sure that the columns storing the SQL are large enough to contain the >>>> whole statement. Otherwise there is no limit on the statement size >>>> in Sequoia, we do insert Blobs of several MB so few KB should not be >>>> a problem. >>>> >>> This should be no problem, since if we use only one controller all does >>> work well. Even larger blobs. >>> >>> Thanks for your help >>> Markus Wolf >>> >>> >>> >>>> Keep us posted with your progress, Emmanuel >>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> >>>>> Hi Robert, >>>>> >>>>> >>>>> >>>>>> What group communications are you using? How were you able to >>>>>> deduce that the problems were coming from group communications? >>>>>> >>>>>> >>>>>> >>>>> we are using JGroups (default with 2.10.10). We asume it is the >>>>> group communication, because when we have hanging transactions we >>>>> lookup the transaction ids and then do a "dump transaction <id>" on >>>>> both controllers. On one of them (which got the initial statement) >>>>> the whole transaction statements are available, but on the second >>>>> all parts - from the statement including the blob to the end of the >>>>> transaction - are missing. Therefore we asume that it was the >>>>> group communication. Also with only one controller all does work >>>>> well. >>>>> >>>>> Thanks Markus Wolf >>>>> >>>>> >>>>> >>>>>> Thanks, Robert >>>>>> >>>>>> On 9/18/08 7:07 AM, "Markus Wolf" <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> Hi Emmanuel, >>>>>> >>>>>> we have had do reinitalize the whole cluster. To our luck this >>>>>> was only a test environment and no production system. After >>>>>> further investigating the problem we tracked it down to an error >>>>>> in the controller group communication. We are uploading files in >>>>>> our webapp which are afterwards stored as blobs in the database. >>>>>> The whole process does work when only one controller is running, >>>>>> but if the second controller is active only part of the >>>>>> transaction is replicated to the second one and the transaction >>>>>> on both controller hangs. The problem also only occurs if the >>>>>> file is larger than 2,7k (at least in our tests). We also tested >>>>>> with a 27k file which result in hanging transactions. No >>>>>> exception is thrown from the controller or no log entry is done. >>>>>> >>>>>> Is there an option to specify the file limits? Or maybe could it >>>>>> be related to our hsqldb recovery log and blob handling? >>>>>> >>>>>> Thanks for any help Markus Wolf >>>>>> >>>>>> >>>>>> >>>>>>>>>> we are using Sequoia 2.10.10 and have two controllers on >>>>>>>>>> dedicated systems each with one backend database. >>>>>>>>>> Yesterday I started a backup on controller2 and after >>>>>>>>>> that the database was not enabled again. So I restarted >>>>>>>>>> the virtual-database but since that the controller hangs. >>>>>>>>>> After searching for some info about the problem (no log >>>>>>>>>> file entries) I dicovered that there are 7 pending >>>>>>>>>> transactions on controller1 which seem to block the >>>>>>>>>> controller. They do not seem to timeout and I have found >>>>>>>>>> no option to rollback/timeout them with the console or >>>>>>>>>> JMX. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Yes, it is true that there is no option in the console to >>>>>>>>> rollback a transaction, this is probably a feature we >>>>>>>>> should add. If you close the client connections (can >>>>>>>>> probably easily be done by resetting the app. side >>>>>>>>> connection pool) that will automatically rollback the >>>>>>>>> connections. Open transactions usually come from an >>>>>>>>> application that does not commit/rollback transactions in >>>>>>>>> all cases (and thus transactions remain uncommitted). >>>>>>>>> Another caveat of the JDBC API is that a commit/rollback >>>>>>>>> automatically starts a new transaction. So if you don't >>>>>>>>> force the connection to setAutoCommit(true) after a >>>>>>>>> commit/rollback they will be in a new transaction. And >>>>>>>>> Sequoia can only perform enable.disable/backup/shutdown >>>>>>>>> operations on transaction boundaries. We never implemented >>>>>>>>> a kill/abort command because it cannot be implemented >>>>>>>>> deterministically (what do you do is the transaction has >>>>>>>>> already committed on a backend and you try to cancel >>>>>>>>> cluster-wide?). This could however be implemented for open >>>>>>>>> transaction with no active request. Feel free to add a >>>>>>>>> feature request in JIRA if you think this could be a useful >>>>>>>>> tool to have. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am I missing something? Can someone give me a hint on how >>>>>>>>>> to stabilize the system again. Or is the only solution >>>>>>>>>> to kill both controllers, initialize the database again >>>>>>>>>> (or restore from dump) and synchronize the controllers >>>>>>>>>> again afterwards? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> In your case, the 2nd backend was still in backup mode >>>>>>>>> waiting for transactions to complete. If you are not able >>>>>>>>> to terminate the transactions by closing your application >>>>>>>>> connections, you can reset the virtual database by using a >>>>>>>>> force shutdown (this will abort pending transactions). You >>>>>>>>> will probably have to resynchronize the 2nd controller with >>>>>>>>> its backend upon restart to make sure that they are >>>>>>>>> properly synchronized. >>>>>>>>> >>>>>>>>> Hope this helps, Emmanuel >>>>>>>>> >>>>>>>>> > - -- NMMN - New Media Markets & Networks GmbH Geschäftsführung: Kfm. Michael Schütt Finanzamt HH-Altona UStID DE 812 699 852 HRB 71102 Hamburg HypoVereinsbank - BLZ 200 300 00 - Konto-Nr. 156 29 82 http://www.nmmn.com Tel.: +49 40 284 118 -0 Langbehnstrasse 6 Entwicklung: -720 22761 Hamburg Fax: -999 Rufen Sie uns kostenlos an: http://www.nmmn.com/call/software +++ Hausmesse am 14.11.2008 von 10:00 bis 16:00 Uhr +++ Überzeugen Sie sich auf unserer Hausmesse von unseren Produkten und Dienstleistungen! Weitere Informationen und Anmeldung unter: http://www.nmmn.com/hausmesse/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI06r/DBHISU1oEKERAvYWAJ9F4o5MQUauQw4xyXrDWI1Hygm47QCfaknn q+6AoLyDsVtZRTc7R4+jk5I= =V5lE -----END PGP SIGNATURE----- _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
