AutoRecover state and multiple application servers

[sack]

Hello everybody u'r rocks,
We have an issue with one frontal and 2 application servers.
The JavaMonitor is on the WO server 1.
If I restart the Javamonitor on the WO server 1, all the Autorecover states are unset on the WO server 2.

Autorecover button seems to update only the local siteconfig.xml and not all the servers.
Thx

[giles-carre]

Hi,

I work with sack.

More details following, because it's not exactly "Autorecover button seems to update only the local siteconfig.xml and not all the servers".

Example: 2 servers, with 1 application and 2 instances:

• serv1, with SiteConfig1, inst1 and Wonder JavaMonitor
• serv2, with SiteConfig2, inst2

Any parameter update but autoRecover, is recorded into the 2 SiteConfigs, because any of them include the global configuration to allow site recovery. OK.

But with autoRecover:

• 1. an autoRecover update for inst1 is only recordered into the instance tags structure of SiteConfig1; the autoRecover tag for inst1 into SiteConfig2 is not updated.
• 2. an autoRecover update for inst2 is only recordered into the instance tags structure of SiteConfig2; the autoRecover tag for inst2 into SiteConfig1 is not updated
• 3. when we restart JavaMonitor on serv1, SiteConfig2 is replaced by the values of SiteConfig1 (some synchronization from serv1 to serv2), so the new SiteConfig2 has the autoRecover flag for inst2 set to false, like in SiteConfig1.
• 4. then, if we restart serv2, inst2 doesn't start automatically.

The problem for inst2 comes from item 2 + item 3. It seems that the Apple JavaMonitor works like the Wonder one for item 1 and 2, but doesn't synchronize SiteConfigs (item 3) on restart. So, the problem in item 4 doesn't exist with Apple JavaMonitor (but the difference between the two siteConfigs exists).

I think the origin is in the item 1 and 2. It's a nonsense. I don't know if the bug is from wotaskd or JavaMonitor, but if I use Wonder JavaMonitor with Wonder wotaskd or Apple wotaskd, it's the same thing.

We use WO for a collaborative open source ERP in French Universities (about 80), and everybody using Wonder JavaMonitor with more than one server has this problem. All use Linux servers (I don't know if some of us use MacOS X servers and Wonder wotaskd/JavaMonitor).

Thanks in advance.

Giles

That sounds like a bug in JavaMonitor. You can check Wonder commits to see what changed.

Chuck

On 2014-05-16, 8:32 AM, "giles-carre" wrote:

Hi,

I work with sack.

More details following, because it's not exactly "Autorecover button seems to update only the local siteconfig.xml and not all the servers".

Example: 2 servers, with 1 application and 2 instances:

• serv1, with SiteConfig1, inst1 and Wonder JavaMonitor
• serv2, with SiteConfig2, inst2

When we set any parameter but autoRecover, it's recorded into the 2 SiteConfigs, because any of them include the global configuration to allow site recovery.

But when we set autoRecover:

• 1. for inst1, it's only recorderd into the instance tags structure of SiteConfig1; the autoRecover tag for inst1 into SiteConfig2 is not updated
• 2. for inst2, it's only recorderd into the instance tags structure of SiteConfig2; the autoRecover tag for inst2 into SiteConfig1 is not updated
• when we restart JavaMonitor on serv1, SiteConfig2 is replaced by the values of SiteConfig1, so the new SiteConfig2 has the autoRecover flag for inst2 set to false, like in SiteConfig1
• then, if we restart serv2, inst2 doesn't start

The problem for inst2 comes from item 2 + item 3. It seems that Apple JavaMonitor works like Wonder for item 1 and 2, but doesn't synchronize SiteConfigs (item 3) on restart. So, the problem in item 4 doesn't exist with Apple JavaMonitor.

But I think the origin is in the item 1 and 2. It's a nonsense. I don't know if it's from wotaskd or JavaMonitor, but if I use Wonder JavaMonitor with Wonder wotaskd or Apple wotaskd, it's the same thing.

We use WO for an collaborative open source ERP in French Universities (about 80), and everybody using Wonder has the problem.

Thanks in advance.

Giles

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/579#issuecomment-43345259.

[giles-carre]

You can check Wonder commits to see what changed.

But we used the 10/20/2010 version and, today, we use the 04/29/2014 version. And it's the same thing, not a change. It sounds to me like an old problem!

[giles-carre]

Hi,

This non-broadcast issue of autoRecover or schedulinEnabled attributes is still relevant, even with wotaskd and JavaMonitor 7.0.

Today, we have 129 applications and 417 configured instances running on 3 applications servers, and its a true problem every day.

Description and analyze of the problem:

• an application App has 3 declared instances, one on each of 3 servers

• when I enable the autoRecover (or schedulinEnabled) flag for instance 2 (server 2), for example, only the server 2 SiteConfig.xml is updated, not the ones son serv1 or serv 3 :
  SiteConfig.xml @ serv 1 : instance 1 = N, instance 2 = N, instance 3 = N
  SiteConfig.xml @ serv 2 : instance 1 = N, instance 2 = Y, instance 3 = N
  SiteConfig.xml @ serv 3 : instance 1 = N, instance 2 = N, instance 3 = N

• when JavaMonitor (running on serv 1) is restarted (every night, we reboot all servers), the SiteConfig.xml on Serv2 and Serv 3 are synchronized from SiteConfig.xml on Serv 1, which has a disabled flag

• so the flags in SiteConfig.xml @ serv2 (or serv 3) are lost and many applications never automaticaly restart

In this schema, SiteConfig.xml doesn't provide redundancy. All SiteConfig.xml should contain exactly the same settings.

Giles