That would be great if the application connected directly to mysql using
the mysql-connector.jar (within jboss).  I am using (attempting to) use
sequoia here, so the application connects to the controller to exec the
sql. This in turn also has it's layer of virtual users (from what I can
gather) and this is what I have setup.  So the application now talks to
the sequoia controllers who then in turn execute the sql to the database
servers  Unless I've missed a gigantic step?

 

________________________________

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Hodges
Sent: Tuesday, May 06, 2008 2:26 PM
To: Sequoia general mailing list
Subject: Re: [Sequoia] Hello Again

 

Hi Jonathan, 

Why don't you just add privileges to your user?  The following works for
me: 

mysql> grant all on *.* to myuser@'somehost' identified by
'secretpassword'; 

Note that if these tables load a lot of data it's likely to be a bit
slow since update rates in Sequoia are not the same as going against a
native database.  In that case it would be worth considering another
approach for restart. 

Cheers, Robert


On 5/6/08 11:19 AM, "Jonathan Poole" <[EMAIL PROTECTED]> wrote:

Emmanuel,

Sorry for the delay, been off with quite a head cold.

I've looked into this a bit more and found the culprit where our
problems start.

We are using jboss 4.2.2 as our application server.  On startup, a
module or two (possibly more) insists in the ability to drop table if
exists, and recreate, re-seed the tables when the application server
starts up.

The problem I guess is obvious, I need to be able to grant the user the
ability to drop/create insert/update delete, create index, etc when our
application server starts up.

A better question would probably be, can this be enabled, if so how? Or
should we totally change how things start on our application server?

I have an output of the sequoia log (it's quite big 2.4M) I could
compress and send to you individually if requested.

Regards,
Jonathan D. Poole

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>  On Behalf Of
Emmanuel Cecchet
Sent: Monday, April 28, 2008 8:57 AM
To: Sequoia general mailing list
Subject: Re: [Sequoia] Hello Again

Did you try to set the logger to DEBUG like I mentioned earlier on to
get more information about the problem?

Emmanuel

Jonathan Poole wrote:
> Any workaround?  Is there something we can adjust in the code level to
> get around this?
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>  On Behalf Of
> Emmanuel Cecchet
> Sent: Monday, April 28, 2008 8:40 AM
> To: Sequoia general mailing list
> Subject: Re: [Sequoia] Hello Again
>
> Jonathan,
>
> 2.10.10 would be much better unfortunately there is no release yet of
> this version. According to Robert, this is their next thing on their
> todo list but they are also working on their new asynchronous
> replication project so I don't know when that is really going to
happen.
>
> We probably need to find an alternative way of doing releases
otherwise
> we will never get that thing out!
>
> Sorry about that but there is not much I can do at the moment unless I

> start doing my own releases which is not really part of my plans for
> now.
>
> All suggestions are welcome,
> Emmanuel
>
>
>> sequoia-2.10.9-bin is the version I'm using.  Is there a different
>> version I'm to be running?
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>  On Behalf Of
>> Emmanuel Cecchet
>> Sent: Friday, April 25, 2008 3:25 PM
>> To: Sequoia general mailing list
>> Subject: Re: [Sequoia] Hello Again
>>
>> Hi Jonathan,
>>
>>
>>> 2008-04-25 14:18:07,605 ERROR sequoia.controller.recoverylog
Recovery
>>>
>
>
>>> log was unable to update request completion status:
>>> [EMAIL PROTECTED]
>>> <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]> : UPDATE logtable
>>> SET exec_status='F',update_count=0,exec_time=0 WHERE log_id=-1
>>>
>>>
>>>
>> Do you have more information about the exception that caused the
>>
> error?
>
>> If you don't get more information, try to set the recovery log logger

>> (in log4j.properties) to DEBUG.
>>
>>
>>> How do I resolve this recovery log issue?
>>>
>>>
>>>
>> Just to be sure, you are using Sequoia 2.10.9?
>> It might be a problem with exec_status column type.
>>
>> Keep us posted as soon as you have more details.
>> Thanks,
>> Emmanuel
>> _______________________________________________
>>
>>

_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia

This e-mail message is confidential, may be privileged and is intended
for the exclusive use of the addressee. Any other person is strictly
prohibited from disclosing, distributing or reproducing it. If the
addressee cannot be reached or is unknown to you, please inform us
immediately and delete this e-mail message and destroy all copies. Thank
you.


_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia



-- 
Robert Hodges, CTO, Continuent, Inc.
Email:  [EMAIL PROTECTED]
Mobile:  +1-510-501-3728  Skype:  hodgesrm

_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia

Reply via email to