On 7/8/13 1:40 PM, "Marcus Sorensen" wrote:
>So to the original question, is it your opinion that a single
>management server (non-clustered) should also fence itself, or wait
>for the database connection to be restored?
Yes, my opinion is that a single management server should also fence
itse
So to the original question, is it your opinion that a single
management server (non-clustered) should also fence itself, or wait
for the database connection to be restored?
On Mon, Jul 8, 2013 at 2:03 PM, Kelven Yang wrote:
>
>
> On 7/7/13 3:36 PM, "Marcus Sorensen" wrote:
>
>>I think there are
Yes, I have a sample set up. It took some looking through the code,
but for cloud db one can set up multi-database at the JDBC driver
level with no modifications. For usage and awsapi databases, this
isn't currently possible because there are some parameters missing for
db.properties, the aforement
On 7/7/13 9:08 PM, "Marcus Sorensen" wrote:
>Looks like there's no "db.usage.url.params", either. Is there a reason
>for it, or was it just implemented quickly?
>
>On Sun, Jul 7, 2013 at 4:36 PM, Marcus Sorensen
>wrote:
>> I think there are two separate issues here.
>>
>> 1) The management ser
On 7/7/13 3:36 PM, "Marcus Sorensen" wrote:
>I think there are two separate issues here.
>
>1) The management server uses the database to determine cluster
>membership, and if no database connection can be made, the management
>server fences itself (shuts down). This is good, but in the case wh
Looks like there's no "db.usage.url.params", either. Is there a reason
for it, or was it just implemented quickly?
On Sun, Jul 7, 2013 at 4:36 PM, Marcus Sorensen wrote:
> I think there are two separate issues here.
>
> 1) The management server uses the database to determine cluster
> membership,
I think there are two separate issues here.
1) The management server uses the database to determine cluster
membership, and if no database connection can be made, the management
server fences itself (shuts down). This is good, but in the case where
there's only one management server (no cluster in
Oh, and I should correct myself, it doesn't crash, it seems that the
management server fences itself because it can't talk to the database.
On Sun, Jul 7, 2013 at 12:59 AM, Marcus Sorensen wrote:
> Ok. After a cursory look, I've seen that the autoReconnect is kind of
> a bad option for jdbc. I've
Ok. After a cursory look, I've seen that the autoReconnect is kind of
a bad option for jdbc. I've also found this, which seems kind of hairy
for what I want to do:
http://dev.mysql.com/doc/refman/5.0/en/connector-j-usagenotes-j2ee-concepts-managing-load-balanced-connections.html
I don't necessari
Hi,
On 07/07/2013 08:45 AM, Marcus Sorensen wrote:
I see that my db.properties has db.cloud.autoReconnect=true, which
translates to setting autoReconnect in the jdbc driver connection in
utils/src/com/cloud/utils/db/Transaction.java. I also see that if I
manually trigger the issue I get:
Just
I see that my db.properties has db.cloud.autoReconnect=true, which
translates to setting autoReconnect in the jdbc driver connection in
utils/src/com/cloud/utils/db/Transaction.java. I also see that if I
manually trigger the issue I get:
013-07-07 00:42:50,502 ERROR [cloud.cluster.ClusterManagerIm
I've noticed that the cloudstack management server creates persistent
connections to the database, and crashes if the database connection is
lost. I haven't looked at the code yet, but I was wondering if anyone
knew about what was going on here, if it's simply not set up to
gracefully handle reconn
12 matches
Mail list logo
