Support Article

Pega CTI causes issues after certain number of users



A PegaCALL 713ML3 application running on JBoss application Server. The system does not perform as expected. After 12-13 operators login to the system, further logins, will cause the Interaction Portal to hang. Any operators logged in after this point will not be able to perform any CTI operations.


Not applicable.

Steps to Reproduce

  1. Login to the Pega CTI.
  2.  After 12 users have logged in, the system performance degrades.
  3. Observe: from 13th user the login will cause the waiting spinning icon to appear and never goes away.

Root Cause

A defect or configuration issue in the operating environment


If a PegaCALL application has been configured with No-Plugin option in the Presence-Agent, the system will use the HTTP Long Polling. Unlike, ActiveX and Applet, this protocol will consume server threads in Application Server. If Pega has been deployed with EAR file option, the default JBoss resource limit is not sufficient with 20 or more concurrent operators. To scale up the system, the below configurations is recommended:

1) In standalone-full.xml, increase the slsb-strict-max-pool and mdb-strict-max-pool to 100

<subsystem xmlns="urn:jboss:domain:ejb3:1.4">
        <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
    <stateful default-access-timeout="5000" cache-ref="simple"/>
    <singleton default-access-timeout="5000"/>
       <resource-adapter-ref resource-adapter-name="${ejb.resource-adapter-name:hornetq-ra}"/>
       <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
        <strict-max-pool name="slsb-strict-max-pool" max-pool-size="100" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
      <strict-max-pool name="mdb-strict-max-pool" max-pool-size="100" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>

    <cache name="simple" aliases="NoPassivationCache"/>
    <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
    <file-passivation-store name="file"/>
    <async thread-pool-name="default"/>
    <timer-service thread-pool-name="default">
    <data-store path="timer-service-data" relative-to=""/>
    <remote connector-ref="remoting-connector" thread-pool-name="default"/>
      <thread-pool name="default">
        <max-threads count="10"/>
            <keepalive-time time="100" unit="milliseconds"/>
    <iiop enable-by-default="false" use-qualified-name="false"/>
    <default-security-domain value="other"/>
    <default-missing-method-permissions-deny-access value="true"/>

2) In standalone-full.xml, increase the min/max pool size of AsyncConnectionFactory to 40/100.

<pooled-connection-factory name="AsyncConnectionFactory">
    <transaction mode="xa"/>

        <connector-ref connector-name="in-vm"/>
        <entry name="java:/jms/PRAsyncTCF"/>

3) In standalone-full.xml, increase the http connector max-connections to 200

<subsystem xmlns="urn:jboss:domain:web:2.1" default-virtual-server="default-host" >
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"  max-connections="200"/>
    <virtual-server name="default-host" enable-welcome-root="true">
        <alias name="localhost"/>
        <alias name=""/>

The pool size of slsb-strict-max-pool and mdb-strict-max-pool should be the same.
The concurrent CIT user community is approx 75% of this pool size.


Published July 15, 2016 - Updated July 31, 2016

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.