J2EE Clustering with JBoss
Pages: 1, 2, 3
Scheduler Service
The JBoss 3 Scheduler service is covered in detail by the JBoss 3: Administration and Development book. It has three interdependent components:
ScheduleManager, which serves as a centralized registry for registering and executing schedules.ScheduleProvider, which abstracts the custom logic that creates schedules.Schedulable, which represents a task that is executed at scheduled times.
Often, applications need to schedule tasks that have to be executed once in the scope of the application, whether it is running standalone or in a cluster of multiple nodes. Examples of such tasks include regular database cleanup, email notifications, and scheduled reports.
All JBoss ScheduleProvider services accept an MBean attribute
that enables them to schedule tasks on only one node in the cluster (of one or
more nodes). The attribute name is HASingleton and its value is a
Boolean type. When set to True, all ScheduleProvider
MBeans registered with the same name and deployed in the same cluster partition
will coordinate and make sure that the schedule is only provided to the
schedule manager on one of the nodes. When set to False, each of
the schedule providers will act independently and as a result, they will all
schedule tasks with their local scheduler managers. The default value of the
attribute is True, which allows transparent transition of standalone schedule
providers to a clustered environment.
The name of the partition where a singleton schedule provider service will
be deployed can be set via the PartitionName attribute. By default,
the value assumes the default JBoss partition name.
Here is an excerpt from the example service archive descriptor cluster-examples-service.xml, located in the server/all/farm directory in the JBoss installation.
<!--
| This MBean is an example of an HA Schedule Target
| which is identical to a regular Schedule Target
| (the example class is the same, just the MBean has different names)
- ->
<mbean code="org.jboss.varia.scheduler.example.SchedulableMBeanExample"
name="jboss.examples:service=HASchedulableMBeanExample">
</mbean>
<!- - -->
<!--
| The Schedule Manager has to be started whenever
| schedules are needed.
|
| Uncomment only if not started by
| another service (e.g. schedule-manager-service.xml)
- ->
<mbean code="org.jboss.varia.scheduler.ScheduleManager"
name="jboss:service=ScheduleManager">
<attribute name="StartAtStartup">true</attribute>
</mbean>
<!- - -->
<!--
| This is a single schedule Provider which works like the
| one in schedule-manager-service.xml
|
| The key difference is the explicit use of the HASingleton MBean attribute
| to make the provider a clustered singleton.
| When HASingleton is set to true the MBean will usually declare dependency
| on a cluster partition. In this case it is the DefaultPartition.
| When not explicitly set the attribute defaults to true.
|
| The same attribute can also be used for the other schedule providers as well:
| DBScheduleProvider and XMLScheduleProvider
|
|
- ->
<mbean code="org.jboss.varia.scheduler.SingleScheduleProvider"
name="jboss:service=HASingleScheduleProvider">
<depends>jboss:service=DefaultPartition</depends>
<depends>jboss:service=ScheduleManager</depends>
<depends>jboss.examples:service=HASchedulableMBeanExample</depends>
<attribute name="HASingleton">true</attribute>
<attribute name="ScheduleManagerName">jboss:service=ScheduleManager</attribute>
<attribute name="TargetName">jboss:service=HASchedulableMBeanExample</attribute>
<attribute name="TargetMethod">
;hit( NOTIFICATION, DATE, REPETITIONS, SCHEDULER_NAME, java.lang.String )
</attribute>
<attribute name="DateFormat"></attribute>
<attribute name="StartDate">NOW</attribute>
<attribute name="Period">10000</attribute>
<attribute name="Repetitions">10</attribute>
</mbean>
<!- - --> The deployment descriptor above is almost identical to the one provided by
schedule-manager-service.xml but is intended to be deployed via
farming. Although not necessary, since the default value is True, the
descriptor specifies the HASingleton attribute of the schedule
provider for illustration of its usage.
Notification Service
When it comes to reliable, mission-critical, and sophisticated J2EE messaging, one API stands out: JMS. The JBossMQ service is a robust JMS implementation that meets the high standards commanded by the API for distributed, transactional, and secure messaging. Then why another notification service?
Most typical clustered applications are deployed in a symmetric, homogeneous environment where components need to notify each other about various lifecycle or domain-change events, much like AWT and Swing widgets exchange events. This is where the JBoss cluster notifications come in. They fill the need for reliable, quick, and lightweight events. Cluster notifications do not require new skills from developers familiar with JMX, because they comply with the JMX notifications API.
Figure 4. Clustered notification service
If you have used JMX notifications before, the clustering extension should
be a breeze. There are two common ways to employ clustered notifications: by
extending HAServiceMBeanSupport or by delegating the work to
instances of this class.
Let's look at an example that comes with the JBoss distribution. Here is an excerpt from the familiar descriptor cluster-examples-service.xml, located in server/all/farm.
<!--
| This MBean is an example showing how to extend a cluster notification broadcaster
| Use the sendNotiication() operation to trigger new clustered notifications.
| Observe the status of each instance of this mbean in the participating cluster partition nodes.
- ->
<mbean code="org.jboss.ha.jmx.examples.HANotificationBroadcasterExample"
name="jboss.examples:service=HANotificationBroadcasterExample">
<depends>jboss:service=DefaultPartition</depends>
</mbean>
<!- - -->
<!--
| This MBean is an example that shows how to delegate notification services
| to a HANotificationBroadcaster.
| Use the sendNotiication() operation to trigger new clustered notifications.
| Observe the status of each instance of this mbean in the participating cluster partition nodes.
- ->
<mbean code="org.jboss.ha.jmx.examples.HANotificationBroadcasterClientExample"
name="jboss.examples:service=HANotificationBroadcasterClientExample">
<depends>jboss.examples:service=HANotificationBroadcasterExample</depends>
<attribute name="HANotificationBroadcasterName">
jboss.examples:service=HANotificationBroadcasterExample
</attribute>
</mbean>
<!- - --> The MBean implemented by the HANotificationBroadcasterExample
class provides common clustering services like shared distributed state,
replication management, and notifications. It is a convenience class that can
be extended and customized or used as is. Its most important attribute is
PartitionName, which fixates the partition of nodes where all
MBeans with the same name will work together.
The other MBean in this example is implemented by the
HANotificationBroadcasterClientExample class. It uses the former
MBean's services to broadcast notifications to the local listeners, as well
as remote cluster listeners that have subscribed to the
HANotificationBroadcasterExample MBean. At the same time, the
client MBean will also receive all notifications sent through any instance of
the broadcaster. Clear as mud?
