SBL-SMI-00114: The Multithreaded Server has reached the maximum number of concurrent tasks (%1).
Applies to:
Siebel Tools - Version 7.5.3.17 [16285] and later
Information in this document applies to any platform.
Checked for Relevance on June 22, 2012
Symptoms
On : 7.5.3.17 [16285] version, Siebel VB / eScript / COM
When the Java Data Bean API returns errors and exit due to not able to
connect the object manager, hanging or orphan tasks/sessions are left
behind on the object manager.
EXPECTED BEHAVIOR
-----------------------
No running tasks should left behind after the Java Data Bean API finishes running.
ACTUAL BEHAVIOR
-----------------------
Running tasks with Waiting for Command status are left behind after the Java Data Bean API finishes running.
STEPS
-----------------------
By following these steps the issue can be reproduced:
1. Login to Siebel Application, go to Server Administration, and set the
MaxTasks = 100, MinMTServers = 5, MaxMTServers =10 so that the 21th
session will spill over next server
2. Synchronize Siebel Server components, and restart the Siebel Server
3. Open DOS command window, login to Siebel Server Command interface,
run the below command, and you should see 0 task is running:
list comps for comp sccobjmgr_enu
4. Implement a Java Data Bean test program that can simulate x number of current users.
5. Run the JDB test program for 100 users
6. When the JDB program is running, you will see some errors as below on
not able to connect or login due to max out of the task:
a. SBL-SMI-00114: The Multithreaded Server has reached the maximum number of concurrent tasks
b. Could not open a session in 4 attempts
c. Socket had incorrect word size
7. When the JDB program is done. Go back to the Siebel Server Command
interface, run list comps command again, and you will see some tasks are
still running and won’t complete until the session time out.
The same behavior is reproducible after applied 7.5.3.15 QF0FAI for
wrong pw creates hanging sessions behavior logged in CR 10557696
Cause
The dangling task behavior issue was duplicated on internal system.
Change Request # 10590679(Java Data Bean connections error creates hanging OM session) was submitted to report the error.
Solution
To fix the hanging task behavior, please implement the below workaround:
1) Add retry logic to java program to catch a SiebelException upon Siebel login and to retry a fixed number of times.
2) Add the below to the siebel.properties file
siebel.conmgr.retry = 1
3) The siebel.properties file needs to be included in the Java CLASSPATH. For example:
set CLASSPATH=.;D:\siebel.properties;D:\SiebelJI_Common.jar;D:\SiebelJI_enu.jar
References
BUG:10590679 - [CR#12-1XRKL9F][FR#12-1XRKL9Z] JAVA DATA BEAN CONNECTIONS ERROR CREATES HANGING
Applies to:
Product Release: V7 (Enterprise)
Version: 7.5.3.3 [16172] Fin Svcs
Database: Oracle 8.1.7.4
Application Server OS: Sun Solaris 8
Database Server OS: HP-UX 11i
This document was previously published as Siebel SR 38-1287909151.
Symptoms
SBL-SSM-00006We are having problems viewing, and attaching files in Siebel. This problem started after we
upgraded to 7.5.3.3. When we go to view or attach a file in Siebel (any area), and a new IE
browser window is spawned, we receive an error (see attached "Error" file). When the file doesn't
try to spawn a new browser window just the Siebel dialog box, the error doesn't occur. We haven't
changed any code pertaining to file attachments, this problem just started happening after the
upgrade.
Solution
Message 1
For the benefit of other users, the customer received error messages or
had their connection to the Siebel Web Server time out when attempting
to view or attach files in the 7.5.3.3 Siebel Zero Foot Print Web
Client.
Summary:
The Siebel Web Server log files showed multiple occurrences of the error
messages SBL-SSM-00039 and SBL-SSM-00006. Both these error messages are
indicative of communication timeouts between the client and the Siebel
Web Server. Furthermore, the SBL-SSM-00039 and SBL-SSM-00006 messages in
the Siebel Web Server log files preceded a “SBL-SMI-00114: The
Multithreaded Server has reached the maximum number of concurrent tasks
((null))” in the FinsObjMgr log file. Given these errors in the Siebel
log files, it’s not surprising that the clients received the error
message “The requested site is either unavailable or cannot be
found.”
Searching SupportWeb for assistance found Service Request
#38-1144701021. The customer followed the resolution and unchecked the
"Do not save encrypted pages to disk" security option checkbox via
Internet Explorer Tools menu > Internet Options > Advanced tab
> Scroll down to Security. This resolved the situation.
<Continued ...>
Message 2
<Continued ...>
However, as the customer wished to be able to view/add attachments with
this box checked due to security concerns, Change Request 12-LVRDGH was
raised with Engineering.
Regards,
Applies to:
Siebel CRM - Version: 8.1.1.1 [21211] and later [Release: V8 and later ]
Information in this document applies to any platform.
It is Siebel version 8.1.1.1 [21211]. They are using Oracle RAC server v 10g.
Customer is using eProdCfgObjMgr_enu along with Java Data Bean.
For this OM max tasks/Max MT was set to 20:1.
Symptoms
When their Oracle RAC server failover happens and come back online
( from logs it seems it takes about 4-8 secs), these java data bean OM
tasks hung and then this OM runs out of tasks. Then no one can login
until they restart gateway. The Siebel application is not accessed
through the Siebel UI, it is using java databean. One button click would
generate a request that in turn would translate into a Siebel task.They
only see 2-4 Siebel tasks in average
So the issue is the gtway server doesn't update status since MaxTasks is
reached on OM (product configurator), so another MTServer is not
released to accept server requests since that same MT Server is being
used.
We see error in OM logs as follows:
SBL-SMI-00114: The Multithreaded Server ha
s reached the maximum number of concurrent tasks ((null)) connection:7a4
Changes
We suggested customer to test with following settings but it DID NOT
help only delayed the issue being happening in their environment.
Max tasks=100
Max/Min MT = 5
SISNAPI connidle time=320
Cause
Java Bean API leaves tasks hanging which leads OM to run out of
task. This behavior as indicated in "DOC ID 489554.1 - Java Bean API
leaves tasks hanging"
Solution
it seems indeed customer was facing issue indicated in DOC ID
489554.1- Java Bean API leaves tasks hanging. We suggested following
settings, which it seems resolved hang issue where now they do see some
task spike but it goes down within five minutes.
siebel.conmgr.retry = 1
siebel.conmgr.txtimeout=300000
siebel.conmgr.sesstimeout=310
Thank you
Applies to:
Siebel System Software - Version: 7.5.3.5 [16183] - Release: V7
Microsoft Windows 2000
Product Release: V7 (Professional)
Version: 7.5.3.5 [16183]
Database: Microsoft SQL Server 2000 SP3
This document was previously published as Siebel SR 38-2234401231.
Symptoms
SBL-SMI-00114
Hi,
We are having huge performance issues in Production
Environment. The whole system is very slow and none of the users could
generate any correspondence. We had this issue since last thursday and
friday and we enabled the AWE parameter and disabled PAE in the DB
Server as per the bookshelf. The performance was better yesterday. But
it is very slow again today. We need your help and directions as to how
to find the root cause and fix this problem. We are attaching the recent
log files from 2 object manager servers and 2 document servers.
Thank you in advance
With regards
Cause
The customer was running MS SQL Server SP3, and after further
investigation a case was opened with Microsoft support. Microsoft
support concluded it was a known Microsoft SQL Server bug when using
AWE.
Further details can be found in the URL below, please review it to confirm it is applicable for your environment.
http://support.microsoft.com/kb/899761
The customer was instructed to apply SQL Server 2000 SP4 and SQL server 2000 hotfix build 2148 right after it.
Solution
Message 1
For the benefit of other readers:
The
customer was having huge performance issues in Production Environment.
The whole system was very slow and none of the users could generate any
correspondence. The customer then enabled the Addressing Windows
Extensions (AWE) parameter and disabled Physical Addressing Extensions
(PAE) in the DB Server.
The customer was getting the following
error in the DocServer logs associated to a particular complex SQL
statement. The behavior was intermittent and happened when the database
server was running under high work load.
Error Error 1 2005-07-07
06:40:05 SQLError: [37000],[Microsoft][ODBC SQL Server Driver][SQL
Server]There is insufficient system memory to run this query.
ObjMgrSqlLog Detail 4 2005-07-07 06:40:05
***** SQL Statement Failed Execute Time: 338.093 seconds *****
Running the SQL statement against the database could not reproduce the error.
The
customer was running MS SQL Server SP3, and after further investigation
a case was opened with Microsoft support. Microsoft support concluded
it was a known Microsoft SQL Server bug when using AWE.
Further details can be found in the URL below, please review it to confirm it is applicable for your environment.
http://support.microsoft.com/kb/899761
The customer was instructed to apply SQL Server 2000 SP4 and SQL server 2000 hotfix build 2148 right after it.
(1/2)
Message 2
(2/2)
In
case you receive the SQL Server “There is insufficient system memory to
run this query” related error while running on SQL Server SP4 or
earlier with AWE enabled, please first refer to the
http://support.microsoft.com/kb/899761 and confirm if it is applicable
for your environment, then you should contact Microsoft support to
obtain the mentioned hot fix and apply it right after MS SQL Server SP4,
as this hot fix is not currently available for free download from
Microsoft download site.
Kind Regards,
Applies to:
Product Release: V7 (Enterprise)
Version: 7.5.3.4 [16180] Com/Med
Database: Oracle 9.2.0.2
Application Server OS: Microsoft Windows 2000 Advanced Server SP 3
Database Server OS: HP-UX 11i
This document was previously published as Siebel SR 38-1630974251.
Symptoms
SBL-SMI-00114Hi,
We are experiencing a problem with the Server Request Broker Component in one of the
servers since it has reached is maximum tasks (100), and some of them have been running for about
8-10 hours.
We have also noticed that we have about 2 006 Component Requests (created
today) with Status 'Active' for Workflow Process Manager, and 604 Component Requests with status
'Active' for Appointment Booking Engine.
The result is that several users are not able to
use ABS to schedule activities or use other functionality that uses workflow.
We need help
in order to identify what is causing the requests to be in active status and why the tasks in the
server request broker are not getting released.
Best Regards.
João
Solution
Message 1
For the benefit of other readers:
The Appointment Booking System from the Field Service Application
creates one SRBroker connection for every service region used and will
keep this connection permanently open then. A list tasks for comp
SRBroker will show TK_DISP_RUNSTATE = RUNNING.
The default MaxTasks setting of 100 for SRBroker would be sufficient for
a typical number of service regions, but if you use more than about 70
service regions for appointment booking, you need to increase the
MaxTasks setting here.
(70 is just an estimated number for a standard installations - please
use the formula below for an exact calculation of MaxTasks required for
SRBroker)
Following
Technical Note 570: How Synchronous and Asynchronous Server Requests
Work, and How To Tune These Requests for Performance and Availability
MaxTasks for SRBroker should therefore be at least:
<number of service regions>
PLUS
Number of instances of all Interactive (OM) component running on the
server + Number of instances of all Batch components running on the
server + Total number of Siebel Servers in the enterprise + 10 (for
overhead) = X
There should be no negative performance impact from increasing the
SRBroker MaxTasks setting - you may want to round up the number to the
next multiple of 50 or 100 to avoid running into errors like
SBL-SMI-00114: The Multithreaded Server has reached the maximum number of concurrent tasks (100)
for SRBroker.
... to be continued ...
Message 2
... continued:
Change request 12-S1DS4G
"Document requirement of one running SRBRoker task for each Service Region used"
was logged to have this information added to bookshelf.
Applies to:
Siebel System Software - Version: 7.5.3 [16157] and later [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (MidMarket)
Version: 7.5.3.3 [16172] MME
Database: Microsoft SQL Server 2000 SP3
Application Server OS: Microsoft Windows 2000 Advanced Server SP 4
Database Server OS: Microsoft Windows 2000 Advanced Server SP 4
This document was previously published as Siebel SR 38-1280938281.
Symptoms
SBL-SMI-00114
Our Siebel production database server peaks to 100% CPU utilization
intermittently and becomes non-responsive. The object managers and
workflows fail after this happens. Before the upgrade, in 7.0.4 we did
not have this problem. We had the same number of users and the same
functionality. Why is this happening after the upgrade?
I will
attach the log files and the gateway siebns.dat file to this Service
Request. The following is an excerpt from a (Server Request Processor)
log file:
GenericLog GenericError 1 2004-05-10
19:53:49 [Microsoft][ODBC SQL Server Driver][SQL Server]Transaction
(Process ID 98) was deadlocked on lock resources with another process
and has been chosen as the deadlock victim. Rerun the transaction.
Thank you.
Solution
The Siebel Application database server consumed 100% CPU utilization intermittently and became non-responsive.
The Server Request Processor log file had the following message:
GenericLog GenericError 1 2004-05-10
19:53:49 [Microsoft][ODBC SQL Server Driver][SQL Server]Transaction
(Process ID 98) was deadlocked on lock resources with another process
and has been chosen as the deadlock victim. Rerun the transaction.
The following actions have been taken to resolve this unexpected behavior:
1)
The messages in the Server Request Processor log file were related to
"Alert 953: Server Request Processor component many hang or report
ORA-00060: deadlock detected while waiting for resource" on Support but
on this case, it has happened on SQL Server. The workaround provided in
the Alert 953 has been applied and it resolved this particular
unexpected behavior.
2) The customer has re-configured the Object
Manager parameters following the instructions in the “Technical Note
388: How to configure Siebel Object Manager (SOM) in Siebel 7” on
SupportWeb.
3) The customer executed the environment verification
tool (EVT) and applied the suggested recommendations. Please refer to
"Technical Note 467: Environment Verification Tool (EVT) version 1.1
Overview" on SupportWeb for further information regarding this utility.
4) The database server hardware has been upgraded to a new machine with more resources
The
customer would like to set the ‘max degree of parallelism’ to 0 on this
new database server machine. According to Siebel Server Installation
Guide for Microsoft Windows > Creating the Microsoft SQL Server
Database > MS SQL Server Configuration Guidelines:
---
max
degree of parallelism. This option is used to configure Microsoft SQL
Server's use of parallel query plan generation. In general, parallel
query processing creates competition among resources when multiple
simultaneous connections are taking place.
A value of 0 means
that every processor on the database server will be considered in
generating a parallel query plan. A value of 1 means that only one
processor on the database server will be used for a query plan
generation. It is recommended that you set this value to 1, turning off
parallelism, thereby avoiding parallel query plan generation.
---
According to this information, this parameter should be set to 1. But on this same section, you may find out this information:
---
If
you are upgrading to a newer version of the database, set the value to 0
to allow Microsoft SQL Server to use all available CPUs.
---
The
documentation does not clarify which version of SQL Server is related
to this piece of information. Change Request 12-M1U337 has been logged
to request better documentation.
Thank you.
-Siebel Technical Support
תגובות
הוסף רשומת תגובה