<?xml version="1.0"?>

<jarm>
    
    <!--  Parameter to switch monitoring on / off
       
    change during running system possible used to switch monitoring on / off; 
    other monitoring parameters only valid if monitoring is on (except trace parameters)
    Default = on;
    --> 
    <switch>off</switch>

    
    <!-- Parameters responsible for tracing -->
    <tracemode> 
        <!--
        Parameter to switch tracing on / off
        used to switch Single Activity Trace on / off; 
        only if value is on data recipients could get trace data
        Default = on; 
        -->        
        <switch>off</switch>        
    </tracemode> 

    <!-- Logging parameter -->
    <log>
        <!--
        parameter to define how much information is written to the log file. The
        parameter was introduced in 6.30 as a hidden parameter. Starting with 6.30_FP
        it is an official parameter now. Possible values are 0, 1, 2. The higher the
        level the more information is written to the log file.    
        -->
        <level>0</level>
    </log>

        
    <!-- Parameters conserning components -->        
    <comp>

        <!-- Component Monitor Levels
        
        parameter for setting the general component monitor level. At the beginning
        of a request jarm.comp.level is used to set the monitor level for the
        request. This avoids that a change of the parameter would cause mismatching
        start- and endComponent pairs. Only components are treated if their monitor
        level is lower or equal than the level for the request. Three different levels
        are provided: 0, 1, 2. Default is 0 which, is the 6.20 behavior. To simplify
        the access to the value additional to ConfMonitor.getProperties() the method
        ConfMonitor.getComponentLevel() could be used. 
        Default = 0
        -->
        <level>0</level>

        <!-- Component Trace Levels -->
        <trace>
            <!--
            parameter for setting the general component trace level. If Single Activity
            Trace (SAT) is on the default component level is specified by the parameter
            jarm.comp.trace.level (same values possible as with jarm/comp/level). If
            moni toring and tracing are done the most detailed component level specified
            by jarm/comp/level and jarm/comp/trace/level is used. After the execution of
            components has started the component level is fixed for the request. This
            avoids that a change of the parameter would cause mismatching start- and
            endComponent pairs. Only components are treated if their monitor level is
            lower or equal than the level for the request.
            Three different levels are provided: 0, 1, 2. To simplify the access to the
            value additional to ConfMonitor.getProperties()the method
            ConfMonitor.getComponentTraceLevel() could be used.
            -->
            <level>0</level>
        </trace> 

        <!-- Component specific Properties -->
        <properties>
            
            <set>
                <!--                
                parameter for switching the collection of component specific properties on/off. 
                When a new request is started this pa-rameter is checked. If it is switched
                off all component-specific properties are ignored. Additionally the parameter
                is checked when requests are condensed. 
                Default = on
                -->
                <switch>off</switch>
            </set>
            
            <get>
                <!--
                parameter for switching the reading of component specific properties on/off.
                When returning a request or component overview the parameter is checked. If
                it is switched off all component specific properties are ignored. 
                Default = on	
                -->
                <switch>off</switch>
            </get>
        </properties>       
    </comp>    
    
    <!--
    Parameters to limit the number of components per request
    Because of looping applications, missing endRequest() calls or endRequest() 
    calls with a wrong request name more and more components could be added to
    a request. To avoid an overflow there are limits for the number of components
    per request.
    If this number is exceeded the next endRequest() call will finish the request
    even if the name does not match. A subsequent getRequestMonitor() cal will
    then get a new monitor object. Calls using the old object will be skipped.
    Default = 2500
    --> 
    <maxreqcomplow>2500</maxreqcomplow>

    
    <!--
    If this number is exceeded the next startComponent() or endRequest() call
    will end the request. Subsequent calls to the closed monitor object will be
    skipped.
    There are two limits to minimize the number of skipped monitoring calls. The
    lower limit is weak, if no endRequest() is done the number of components will
    still increase. But there are not so many skipped calls. The upper limit will
    definitely limit the number of components.
    Default = 2600
    --> 
    <maxreqcomphigh>2600</maxreqcomphigh>


    <!-- Instrumentation Check -->
    <instrumentation>
        <!--
        starting from 6.30_FP the consistency of the data collection calls is checked.
        The parameter should be used only in the test phase, not during production.
        The output is written to the log file. If the check is on, messages are written
        in following cases:
     		
            Errors (independent of jarm/log/level)

            - There are calls to a request monitor object issued in different
              threads.

	        Warnings (jarm/log/level >= 1)

            - The request monitor object is used after the request is ready
              (max. one mes-sage per request).
            - The end of a request is forced because of too many components.
            - A component is not closed.
            - A component, which was not started, is closed.
        -->
        <check>off</check>
        
    </instrumentation>


<!--
******************************************************************************
                           VMC specific properties                           *
******************************************************************************
-->

    <!-- JTS specific properties -->
    <jts>
        
        <!-- 
        The JTS extended JARM API provides additional overview 
        methods residing in OverviewMonitor. This methods can 
        be used for monitoring of all threads running in the 
        VM-Container on condition that they are JARM instrumented. 
 
        Because of additional overhead caused by VM-Thread-Overview 
        this feature can be switched via this property. In default 
        case, the switch is set off and no overview is returned. 
        The method :
        
            OverviewMonitor#isVmThreadMonitoringActive()
             
        is provided to determine whether VM-Thread-Overview is 
        switched on or off. In case when the switch is set on, 
        the thread state of each VM is saved in shared memory at 
        the begin and end of each JARM request, which cause of course 
        additional overhead as in the usual case but is used to build
        VM-Thread-Overview.        
        -->
        <vmoverview>off</vmoverview>

        <!-- Properties concerning condensing behavior   -->
        <condensing>

            <!--
            To save the performance the system condensing takes place only 
            when maximal shared memory size, defined by "memsize" property, 
            is increased. Consequently, the overview results delivered by 
            OverviewMonitor could be not up-to-date. Setting this property 
            on, avoids this problem but with a bad performance impact. It 
            forces the condensing while calling following methods in
            OverviewMonitor:
            
                - getTopRequests
                - getSummaryOfRequests
                - getTopComponents
                - getComponents
                - getUser
       
           Each time when user invokes one of this methods, condensing takes 
           place. Thus, the whole performance is affected by the amount of 
           calls. This property should not be set on as default.
           
           Default off            
            -->
            <overview>off</overview>

            <!--
            The maximum size of shared memory for uncondensed JARM data. 
            If uncondensed data increases defined size condensing is 
            automatically forced. The value of this property is defined 
            in MegaByte (default 10MB)

            Default 10
            -->
            <memsize>10</memsize>
            
        </condensing>
    </jts>
    
</jarm>
