Home

 

Configure the widget life cycle retry schedule

Communities uses the IBM WebSphere Application Server scheduler to run a scheduled task that processes events in the widget life cycle event queue. You can configure the frequency with which this task runs by editing settings in the communities-config.xml file.

To edit configuration files, use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for details.


You edit settings in the communities-config.xml file to configure the widget life cycle retry schedule. You can define the interval at which the task runs and specify when the scheduler starts the task. The interval property is configured with a Cron schedule.

A Cron schedule has six parts separated by a space. The six parts specify "second minute hourOfDay DayOfMonth Month DayOfWeek". "*" means all values, for example, all days of the week. The seconds must always be specified as zero. For example, "0 30 3 ? * *" means that the task is run daily at 3:30 a.m. "0 30 2 ? * SUN" means that the task is run on Sunday mornings at 2:30 a.m.

For more information about the elements of a Cron schedule, see the following Web page: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.javadoc.doc/public_html/api/com/ibm/websphere/scheduler/UserCalendar.html

To configure the LifecycleRetryQueuedEvents task...

  1. Use the wsadmin client to access and check out the Communities configuration files.

    1. Access the Communities configuration files:

      If you are asked to select a server, you can select any server.

    2. Check out the Communities configuration files...

      CommunitiesConfigService.checkOutConfig("<working_directory>", "cell_name")

      where:

      • <working_directory> is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working while you make changes to them.

      • cell_name is the name of the WebSphere Application Server cell hosting the Lotus Connections feature. This argument is required even in stand-alone deployments. If you do not know the cell name, do one of the following to determine it:

        • Stand-alone deployment: Look at the name after the following in the file system: 

            WAS_HOME\profiles\profile_name\config\cells\

      • Network deployment: Type the following command while in the wsadmin command processor: 

          print AdminControl.getCell()

      For example: 

        CommunitiesConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

  2. To view the current configuration settings...

    CommunitiesConfigService.showConfig()

    After updating any of the configuration settings, you can use this command again to display your updates.

  3. To change display settings for Communities...

    CommunitiesConfigService.updateConfig("<property>", "<value>")

    where:

    • <property> is one of the editable Communities configuration properties.

    • <value> is the new value with which you want to set that property.

    The following table displays the LifecycleRetryQueuedEvents properties that can be updated, and additional information regarding each property and the type of data that you can enter.


    LifecycleRetryQueuedEvents properties
    Header Header
    task.LifecycleRetryQueuedEvents.interval = 0 1 0-23/1 ? * * Specifies the interval at which the life-cycle retry queued events task runs.

    When you change the interval property, the new schedule is registered the next time that Communities is started on any server in the Communities cluster (if there is one). For example: 

      CommunitiesConfigService.updateConfig("task.LifecycleRetryQueuedEvents.interval", "0 1 0-23/1 ? * *")

    task.LifecycleRetryQueuedEvents.startby = "" The startby attribute is not appropriate for this task. Do not enter any value for the parameter; it should always be set to null (empty double quotes).For example: 

      CommunitiesConfigService.updateConfig("task.LifecycleRetryQueuedEvents.startby", "")

  4. After making changes, check the configuration files back in, and do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying property changes for information about how to save and apply your changes.


Administer remote applications

+

Search Tips   |   Advanced Search