Applies to:
Siebel Tools - Version 7.5.3.17 [16285] and laterInformation 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 HANGINGApplies 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: V7Microsoft 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
No comments:
Post a Comment