Remedy - Server - How to enable logging for AR metadata cache related operations in a Remedy 9.x server group

Version 1
    Share:|

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    Remedy AR Mid Tier


    COMPONENT:

    AR System


    APPLIES TO:

    Remedy AR System Server v.9.x



    QUESTION:

    With versions of AR System Server prior to 9 it was possible to see the propagation of metadata updates caused by an admin change in the server group log.
    This was useful as it could be used to confirm that a non-admin server had received the signal to update its cache and to observe the progress, and completion, of the cache refresh.
    In versions 9.x and later a different caching system is used and this information is no longer recorded in the server group log.

    How do you enable similar logging in 9.x and later?


    ANSWER:

    Remedy AR System Servers from version 9.x onward use a new caching system based on a technology called ehcache.
    This is a transactional system and allows for granular updates to the cached metadata without the full copy cache operations that were used in earlier versions.

    In a server group each server uses the Java Messaging System to exchange messages about cache updates with other members of the group.
    By default ehcache uses port 40001 for this service; this is separate to the JMS system running on port 61617 which is used for other server group related messaging.

    The two configuration options which set these values are:
    Peer-listener-port: 40001
    Default-messaging-port: 61617


    To enable logging for ehcache a change needs to be made to the logback_server.xml file which is located in the ARSystem/conf directory. 

    Edit this file and change the following entry:
    .........................
        <logger name="net.sf.ehcache.distribution" level="warn"
            additivity="false">
            <appender-ref ref="ServerGroupLog" />
            <appender-ref ref="AlwaysOnLog" />
            <appender-ref ref="ServerGroupLogToForm" />
        </logger>
    .........................

    Replace the level value of warn with debug so that it reads:
    .........................
        <logger name="net.sf.ehcache.distribution" level="
    debug"
            additivity="false">
            <appender-ref ref="ServerGroupLog" />
            <appender-ref ref="AlwaysOnLog" />
            <appender-ref ref="ServerGroupLogToForm" />
        </logger>
    .........................


    Now use a client, login as Demo, and open the AR System Administration: Server Information form and go to the Log Files tab.

    Enable the Server Group Log, check the Reload Log Conf File check box and click OK or Apply:

              User-added image

    This will enable server group related ehcache operations to the server group log file.

    To see the logging in action make a workflow/form change on the administration server in your group and check the server group log files on the servers.

    You should see entries for RMIPeerCache similar to these:
    .................................
    RMICachePeer for cache formCache: remote remove received for key: /Form/3557
    RMICachePeer for cache serverGroupCache: remote put received. Element is: [ key = /ObjTimestamp/MetadataChangeTime/Schema/UPDATE, value=1488297438099, version=1, hitCount=0, CreationTime = 1488297439000, LastAccessTime = 1488297439056 ]
    RMICachePeer for cache serverGroupCache: remote put received. Element is: [ key = /ObjTimestamp/MetadataChangeTime, value=1488297438099, version=1, hitCount=0, CreationTime = 1488297439000, LastAccessTime = 1488297439056 ]
    RMICachePeer for cache serverGroupCache: remote put received. Element is: [ key = /ObjTimestamp/MetadataChangeTime/Schema/UPDATE, value=1488297438537, version=1, hitCount=0, CreationTime = 1488297439000, LastAccessTime = 1488297439057 ]
    RMICachePeer for cache serverGroupCache: remote put received. Element is: [ key = /ObjTimestamp/MetadataChangeTime, value=1488297438537, version=1, hitCount=0, CreationTime = 1488297439000, LastAccessTime = 1488297439057 ]
    RMICachePeer for cache domainKeyCache: remote put received. Element is: [ key = /Form/IdByName/WSTest, value=3557, version=1, hitCount=0, CreationTime = 1488297439000, LastAccessTime = 1488297439057 ]
    RMICachePeer for cache domainKeyCache: remote put received. Element is: [ key = /Form/IdByName/WSTest, value=3557, version=1, hitCount=0, CreationTime = 1488297439000, LastAccessTime = 1488297439057 ]
    RMICachePeer for cache formCache: remote remove received for key: /Form/3557
    .................................


    In the above a field was deleted from and form called WSTest with schema ID 3557.

    One thing to note is that only the details of what has changed is signalled, not the actual metadata.
    The receiving server will flag/delete the modified object(s) in its cache and will only read any new data from the database when a thread accesses the object the first time after the update.
    This is much more efficient than the full re-cache that earlier versions performed.

     


    Article Number:

    000132049


    Article Type:

    FAQ/Procedural



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles