LiveCycle Cluster Verification

On top of J2EE clustering, LiveCycle is clustered using Gemfire Distributed Cache. In cluster deployments, it is important that all the members of a LiveCycle cluster are able to find each other so that they can keep their individual caches in synchronization with one another. LiveCycle Cluster is configured properly or not can be identified based on two key indicators. The following are the key indicators.

  • Clustered Scheduler Service
  • Gemfire Logs

JBoss

Clustered Scheduler Service

In JBoss server logs you can find the following messages which show that the scheduler service is started in a clustered mode.

2011-10-19 14:00:47,681 INFO [org.quartz.core.QuartzScheduler] (main) Scheduler IDPSchedulerService_$_nodeA1319013046386 started.

IDPSchedulerService_$_ <hostname>XXXXXXXXXXXX pattern log message confirms the clustered mode.

Gemfire logs

You can find the Gemfire log at the following location

<adobe_temp_dir>/adobejb_<server_name>/Caching/Gemfire.log

Here <adobe_temp_dir> is the temp directory which you choose on LCM screen during EAR configuration.

<server_name> is the value assigned to the following JVM argument.

-Dadobeidp.serverName

Check Gemfire log on the node which that started first, you see the following messages

[info 2011/10/19 13:58:02.644 IST GemfireCacheAdapter <main> tid=0x9] GemFire P2P Listener started on  tcp:///192.168.2.3:65032

[config 2011/10/19 13:58:07.359 IST GemfireCacheAdapter <main> tid=0x9] This member, nodeA:28438, is becoming group coordinator.

[info 2011/10/19 13:58:07.375 IST GemfireCacheAdapter <main> tid=0x9] Entered into membership in group GF6.5.1.17 with ID nodeA<v0>:28438/65032.

[info 2011/10/19 13:58:07.375 IST GemfireCacheAdapter <main> tid=0x9] Starting DistributionManager nodeA<v0>:28438/65032.

[info 2011/10/19 13:58:07.375 IST GemfireCacheAdapter <main> tid=0x9] Initial (membershipManager) view =  [nodeA<v0>:28438/65032]

[info 2011/10/19 13:58:07.375 IST GemfireCacheAdapter <main> tid=0x9] Admitting member <nodeA<v0>:28438/65032>. Now there are 1 non-admin member(s).

[info 2011/10/19 13:58:07.375 IST GemfireCacheAdapter <main> tid=0x9] nodeA<v0>:28438/65032 is the elder and the only member.

[info 2011/10/19 13:58:07.422 IST GemfireCacheAdapter <main> tid=0x9] Did not hear back from any other system. I am the first one.

[info 2011/10/19 13:58:07.422 IST GemfireCacheAdapter <main> tid=0x9] DistributionManager nodeA<v0>:28438/65032 started on 239.192.81.1[33789]. There were 0 other DMs. others: []

Note: Initially the node which started first in the cluster is the only member.

After some time when other nodes started you see the following messages in Gemfire logs of the previously started node.

[info 2011/10/19 13:58:34.425 IST GemfireCacheAdapter <ViewHandler> tid=0x149] Membership: sending new view [[nodeA<v0>:28438|1] [nodeA<v0>:28438/65032, nodeB<v1>:14970/51663]] (2 mbrs)

[info 2011/10/19 13:58:34.457 IST GemfireCacheAdapter <UDP Incoming Message Handler> tid=0x133] Membership: received new view  [nodeA<v0>:28438|1] [nodeA<v0>:28438/65032, nodeB<v1>:14970/51663]

[info 2011/10/19 13:58:34.488 IST GemfireCacheAdapter <View Message Processor> tid=0x14f] Admitting member <nodeB<v1>:14970/51663>. Now there are 2 non-admin member(s).

Note: We can see here that the previously started node received a new view with new members added to the view. This node admitted the new member and total number of member are now two.

Check Gemfire log at the node which started later (At least one node of the cluster is already running), you see the following messages.

[info 2011/10/19 13:58:08.913 IST GemfireCacheAdapter <main> tid=0x9] GemFire P2P Listener started on  tcp:///192.168.2.4:51663

[info 2011/10/19 13:58:22.084 IST GemfireCacheAdapter <main> tid=0x9] Attempting to join distributed system whose membership coordinator is nodeA<v0>:28438 using membership ID nodeB:14970

[info 2011/10/19 13:58:38.043 IST GemfireCacheAdapter <main> tid=0x9] Entered into membership in group GF6.5.1.17 with ID nodeB<v1>:14970/51663.

[info 2011/10/19 13:58:38.058 IST GemfireCacheAdapter <main> tid=0x9] Starting DistributionManager nodeB<v1>:14970/51663.

[info 2011/10/19 13:58:38.058 IST GemfireCacheAdapter <main> tid=0x9] Initial (membershipManager) view =  [nodeA<v0>:28438/65032, nodeB<v1>:14970/51663]

[info 2011/10/19 13:58:38.058 IST GemfireCacheAdapter <main> tid=0x9] Admitting member <nodeA<v0>:28438/65032>. Now there are 1 non-admin member(s).

[info 2011/10/19 13:58:38.058 IST GemfireCacheAdapter <main> tid=0x9] Admitting member <nodeB<v1>:14970/51663>. Now there are 2 non-admin member(s).

[info 2011/10/19 13:58:38.292 IST GemfireCacheAdapter <main> tid=0x9] DistributionManager nodeB<v1>:14970/51663 started on 239.192.81.1[33789]. There were 1 other DMs. others: [nodeA<v0>:28438/65032]

Note: The node started last detects the previously started node(s).

Weblogic

Clustered Scheduler Service

In <server name>.out  file created by the WebLogic Server, you can find following messages which shows that the scheduler service is started in a clustered mode.

13:12:50,970  INFO QuartzScheduler:455 – Scheduler IDPSchedulerService_$_nodeA1318405370787 started.

IDPSchedulerService_$_ <hostname>XXXXXXXXXXXX pattern log message confirms the clustered mode.

Gemfire Logs

You can find the Gemfire log at <adobe_temp_dir>/adobewl_<hostname>/Caching/Gemfire.log

Here <adobe_temp_dir> is the temp directory which you choose on LCM configuration screen during ear configuration.

The log observation is the same as mentioned in the Gemfire Logs section of JBoss.

WebSphere

Clustered Scheduler Service

In WebSphere server System.out  file you can find following log messages which shows that scheduler service is started in a clustered mode.

[10/19/11 9:51:23:432 IST] 00000017 QuartzSchedul I org.quartz.core.QuartzScheduler start Scheduler IDPSchedulerService_$_nodeA1318998083229 started

IDPSchedulerService_$_ <hostname>XXXXXXXXXXXX pattern log message confirmed the clustered mode.

Gemfire Logs

You can find Gemfire logs at the following location

<adobe_temp_dir>/adobews_*/Caching/Gemfire.log

Here <adobe_temp_dir> is the temp directory which you choose on LCM configuration screen during ear configuration.

The log observation is the same as mentioned in the Gemfire Logs section of JBoss.


VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 10.0/10 (1 vote cast)
LiveCycle Cluster Verification, 10.0 out of 10 based on 1 rating

About Pankaj Parashar

Pankaj Parashar is a Lead Software Engineer at Adobe Systems. He is working for Adobe LiveCycle Enterprise Suite. He looks after cluster deployments and LiveCycle SDK testing. His interests include programming, cloud, big data and analytics. He is based out of Noida, India.
This entry was posted in Adobe LiveCycle ES3 and tagged , , , . Bookmark the permalink.

2 Responses to LiveCycle Cluster Verification

  1. Pingback: LiveCycle – Application Server Clustering Verification | Adobe LiveCycle Blog

  2. Alberto Pedroza says:

    Very useful and clear! I want to ask if LiveCycle ES2.5 or above is able to support WebSphere “clones”. I’m not really clear if cloning is the same as clustering, but WAS guys refers to the cloning process. Also, they ask if LiveCycle “is clonable”? Any idea?

    Regards,
    Alberto P