Search This Blog

SBL-SMI-00033: The client exited without closing the SISNAPI connection


Applies to:

Siebel Finance Call Center - Version: 7.8.2.7 [19234] to 8.1.1 SIA [21111] - Release: V7 to V8
Information in this document applies to any platform.

Symptoms

After a server restart, it can happen that the  SRProc dispatcher task  is terminating itself after 60 seconds.
The following error message can be seen in the SRProc log file:
SBL-SMI-00033: The client exited without closing the SISNAPI connection.
The main  SRProc process however continues to run and in srvrmgr status shows as 'running'.
Tasks will remain in queued status and you need to restart the SRProc component to get pending tasks processed.

Cause


Bug 10643087 has been created to address this behavior. There has been a race condition detected that can cause shutdown of SRProc process.

Solution

For the benefit of other readers:
Quickfix QF 0765 has been built for the Siebel CRM version 7.8.2.7 Fixpack.
The fix for this issue has been included on the following Siebel CRM maintenance releases and later:

Siebel CRM version 7.8.2.12
Siebel CRM version 8.0.0.7
Siebel CRM version 8.1.1.1

References

BUG:10643087 - [CR#12-1QTP7FD][FR#12-1QTP7FY] SRPROC CRASH/TIMEOUT ON SERVER STARTUP.


Applies to:

Siebel System Software - Version: 7.7.2.3 [18361] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.7.2.3 [18361]
Database: Microsoft SQL Server 2000 SP4
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: Microsoft Windows 2003 Server SP1

This document was previously published as Siebel SR 38-2794835661.

Symptoms

SBL-DAT-00306, SBL-DAT-00315, SBL-SVR-01014, SBL-SMI-00033, SBL-CSO-01031, SBL-GEN-09103The SRBroker log file often contains the following error message:
SBL-SMI-00033: The client exited without closing the SISNAPI connection.

The eventlog of the server does not show any errors.
The backups of the database occur at night.
Until now there was no user complaining having lost his session.

Should we be concerned about this error?

Changes

Cause

Change Request Numbers 10641111 and 10641355.

Solution

For the benefit of other readers:

The Customer had installed and was currently in the process of using the Siebel Version 7.7.2.3 product release in their Production environment, when these error messages started to occur with the Server Request Broker (SRBroker) Server Components:

SisnTcpIp    SisnSockError    1    0    2006-01-04 15:00:19     8300: [TCPIP-server] recv() failed for sd=2904 (err=10054 | An existing connection was forcibly closed by the remote host (peer).)

GenericLog    GenericError    1    0    2006-01-04 15:00:19    (smimtses.cpp (350) err=2100033 sys=0) SBL-SMI-00033: The client exited without closing the SISNAPI connection

Through research and investigation, we discovered that these error messages could be safely ignored.  Product Enhancement Change Request Numbers 10641771 and 10641272 have been raised to address this SRBroker error behavior.

We also discovered these error messages occurring here as well :

DBCLog    DBCLogError    1    0    2006-03-03 05:37:23    [Microsoft][ODBC Driver Manager] Invalid cursor state

SRPQueryLogEvt    SRPQueryError    1    0    2006-03-03 05:37:23    SQL Error Rc:0 SqlState:24000 Message:[Microsoft][ODBC Driver Manager] Invalid cursor state

SRPQueryLogEvt    SRPQueryError    1    0    2006-03-03 05:37:23    SQL Error Rc:100 SqlState:00000

These messages are related to known product behavior for which Change Request Numbers 10641111 and 10641355 have already been raised to address. Refer to the following MOS document for related information:


Keywords: SBL-SMI-00033, Forcibly Closed, SISNAPI, Connection, 12-O6HYF2, 12-HH6SF4, ALERT 953



Applies to:

Siebel System Software - Version: 7.5.3 [16157] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.3 [16157]
Database: Oracle 9i
This document was previously published as Siebel SR 38-1497603097.

Symptoms

SBL-SMI-00033 SBL-SMI-00033. The client exited without closing the SISNAPI connection.

We have checked Support web for this error, which suggests no specific way to resolve.

We have tried to stop and restart the Services on our main Server, but this has not fixed the issue.

Can you suggest any other way to rectify this issue?

Solution

The customer had a morning batch process on their Siebel Server and observed many Server Request Broker (SRB) tasks that exited at around the same time (anywhere up to 200 requests in this batch).

The customer restarted the Siebel services on their main server, but this did not fix the exiting SRB tasks.

The last time the Siebel Server machines were re-booted was about one month ago: the machines were re-started which resolved the behavior.

Siebel Technical Support requested the Windows server's application and system event logs, in order to review these to obtain a better understading of the behavior:

The Siebel Servers are shutdown every night for the database to be backed up. It was noted that 22 seconds after the database backup at 04:00, a siebmtshmw.exe process (a multi-threaded server component) raised an exception at 04:00:22 reporting the following error:

---
10/09/2004    04:00:22    Siebel Application    Error    Printers     1002    N/A    S7OFS1    "The description for Event ID ( 1002 ) in Source ( Siebel Application ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: Exception 0xc0000005 at 0x00154030
Thread: 0x00000bf4, Process 0x00001238
---

This means the component crashed. We believed that this was the SRB process. The call stack was included in the event log (but did not show any useful information). This was the first occurence of this crash type. It occured 5 times between this initial occurence and 10:07:59 on the same date. This type of crash did not occur prior to the 10th of September, nor did it occur subsequently.

The error code "Event ID 1002" means that the component experienced a "Disconnect error", which would make sense in that the database was being backed up. It seemed that the component had difficulty re-establishing a connection with the database after the backup. We do not know why the component could not re-establish a connection.

The customer was satisified with this analysis.



Applies to:

Siebel System Software - Version: 7.7.2.2 SIA [18356] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.7.2.2 [18356] Cons Goods
Database: Oracle 9.2.0.4
Application Server OS: Microsoft Windows 2000 Server
Database Server OS: Compaq Tru64 UNIX

This document was previously published as Siebel SR 38-2942604721.

Symptoms

SBL-SMI-00033, SBL-ADM-09217Dear Support,

we have problems to set up the Admin Notification on the Enterprise level via Email.

I already read in the Siebel Bookshelf 7.7 (configuring Siebel Servers, page 76-79) and also in SR# 38-1486557451but I still recieve errors.

We also set up an order confirmation via Email with the same Servername and Serverport as we used for the Admin Notify and that is working fine.

Can you please help?


Please see the attached files.

1 Word Document with 3 Hardcopies showing different Screens/Parameters
2 log files from our QA system

(AdminNotify_38.log, POP3SMTP_1B2C_1_1_43FADED2_808E282E.log)

Best Regards

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other users:

Original Issue:
Customer configured the Admin Notification component on the Enterprise level as documented in the Siebel Bookshelf. While testing the functionality the following error messages were encountered in the AdminNotify_xx.log file:

- SBL-ADM-09217: Error occurred in invoking the notification handler in dll [ssemailntfy] for doing notification configured in named subsystem [AdminEmailAlert] for component [SiebSrvr]
- Socket error 10053: An established connection was aborted by the software in your host machine.
- Unable to connect socket to port 25 on remote host crw-001.ho.u1403.unilever.com
- Socket error 10053: An established connection was aborted by the software in your host machine.

Solution:
After further investigation and reviewing all configuration steps for the Admin Notification component, it was found that behavior was not related to any incorrect configuration of the component.

Further investigation of the error messages logged in the AdminNotify log file revealed the following:

- An established connection was aborted by the software in your host machine.
- Error 10053 means that an established connection has been dropped.

...

Message 2

...

The first part of the error message \'software in your host machine\' that is referred to is actually \'Winsock\' - the TCP/IP component of Windows. The \'protocol error\' referred to in the second text is the TCP protocol, not POP3 or SMTP, etc protocol.
10053 errors are actually quite rare usually, but there are a couple of cases which can cause them; It could be a problem caused by an antivirus software. Some virus scanners have been known to cause these errors.

After excluding the Siebel component from the Antivirus software, Admin Notification alerts were sent out correctly through Emails on port 25.

Keywords:
Socket error 10053; An established connection was aborted by the software in your host machine; Admin Notifictaion; System Alert;

Thanks and Regards,









Applies to:

Siebel System Software - Version: 7.7.2.3 SIA [18361] to 8.1.1.4 SIA [21225] - Release: V7 to V8
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.2.3 [18361] NLD Fin Svcs
Database: Oracle 8.1.7.4
Application Server OS: IBM AIX 5L 5.2
Database Server OS: IBM AIX 5L 5.2

This document was previously published as Siebel SR 38-2424543581.

*** Checked for relevance on 04-May-2011 ***

Symptoms

SBL-SMI-00033We have 2 siebel servers in our enterprise, one running on AIX which hosts the Application OM's, and one on W2K which host Communication Server for CTI.

Upon start-up of our siebel server(AIX), the SRProc component raises a SBL-SMI-00033 error message. This occurs consistantly every time the Siebel server is restarted. If I then manually shutdown and restart just the SRProc component (via the UI), then this component does not raise this error. I also notice that upon startup of the 'Server Request Processor' component shows one open task (via server manager UI). After manual re-start of 'Server Request Processr', there are 2 open tasks.

Please advise what the casue of SBL-SMI-00033, and how we can correct it


Cause

Environment specific

Solution

We tried to see if this was port conflict issue, it was not. However we found that the Encryption Type is RSA for the SRPRoc. we requested to set it to None for SRProc and SRBroker as this typically applies to AOM. We also ensured that after changing the parameter and starting the server it was set to None

In customer's environment RSA encryption had been enabled at the Enterprise level, so they Disabled encryption for SRproc and SRBoker. This helped customer resolve the behavior.





Applies to:

Siebel System Software - Version: 7.7.2.6 [18372] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.7.2.6 [18372]
Database: Microsoft SQL Server 2000 SP3
Application Server OS: Microsoft Windows 2000 Server SP 4
Database Server OS: Microsoft Windows 2000 Server SP 4

This document was previously published as Siebel SR 38-3197311343.

Symptoms

SBL-OSD-00098, SBL-SMI-00033We just had the following error in our Production Siebel
Task 12337 of component SRBroker has ended with error code 2100033 error string SBL-SMI-
00033: The client exited without closing the SISNAPI connection

This type of error happened frequently when we were 7724 level. Now we are patched up to 7726(11-08-206) and we understand that this would no longer happen with 7726.

We have crash_xxx.txt created with this error. No FDR log was created.

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers.

Customer had crash in FINSObjMgr_enu with the following information:

1. Error message in enterprise log:
ServerLog    ProcessExit    1    0    2006-11-22 10:09:19    FINSObjMgr_enu 25638     SBL-OSD-00098   Process exited with error - Internal: The process exited abnormally and the Operating System could not get the exit code

2. This call stack generated from UserDump, because there was no crash or *.fdr file created:
sscfcmn!CSSLocalStringManager::GetLocalString+0x1e
sscfcmn!CSSObjectBase::GetLocalString+0x1f
sscfcmn!CSSObjectBase::IsLocalString+0x26
sscfdm!CSSQuery::UsesTable+0x493
sscfdm!CSSQuery::UpdateFieldSearchSpec+0x6a1
sscfdm!CSSQuery::Parse+0xf1b
sscfdm!CSSQuery::Parse+0xef4
sscfdm!CSSQuery::ParseFieldExpr+0xd63
sscfdm!CSSQuery::GetPhysText+0x47
sscfdm!CSSSqlObj::AddSqlWhereClause+0x336
sscfdm!CSSSqlObj::AddSqlParts+0x208
sscfdm!CSSSqlObj::Execute+0x78a

3. The corresponding FINSObjMgr_enu.log log file has the following info:
ObjMgrBusServiceLog    InvokeMethod    4    0    2006-12-14 10:04:28    Begin: Business Service 'Data Validation Manager' invoke method: 'Validate' at 30c19ad0
ObjMgrBusCompLog    Create    4    0    2006-12-14 10:04:28    Begin: construct BusComp "FINS Validation Rule Set" at 31cb33c0
ObjMgrBusCompLog    Debug    5    0    2006-12-14 10:04:28    BusComp FINS Validation Rule Set has 22 total, 7 NJS, 2 FA, 2 LS, and 0 SeqObj metadata fields.
ObjMgrBusCompLog    Create    4    0


ObjMgrBusCompLog    Create    4    0    2006-12-14 10:04:28    End: construct BusComp "FINS Validation Rule" at 31cbd070
ObjMgrBusCompLog    Create    4    0    2006-12-14 10:04:28    Begin: construct BusComp "FINS Validation Action" at 31cbe588
ObjMgrBusCompLog    Create    4    0    2006-12-14 10:04:28    End: construct BusComp "FINS Validation Action" at 31cbe588
ObjMgrBusCo

4. Errors seen in SRBroker and in SRProc were just a consequence of the crash in FINSObjMgr_enu.

Resolution.
With the information above, it was found that there was a DVM process triggered on the PreWriteRecord of the Service Request BC. After disabling it, the crash did not happen anymore.

Thank you and kind regards,

Siebel Technical Support



Applies to:

Siebel System Software - Version: 7.7.2.2 [18356] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.7.2.2 [18356]
Database: Oracle 9.2.0.6
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: HP-UX 11i

This document was previously published as Siebel SR 38-2879423618.

Symptoms

SBL-SVR-01014, SBL-SMI-00033, SBL-SMI-00049, SBL-CSO-01031, SBL-GEN-09103In our production environment the SRBroker component is using massive amounts of memory. We have a maximum of 100 brokers running, and they are currently using up to 15gb of ram.

Is it normal for the SRBroker to use this much memory? Is there some way we limit this memory usage?

The server this component is running on has 8gb of physical ram.

I have exported the configuration parameters for the SRBroker and attached them for your reference.

Our production environment went live today, so this is a big issue for us. We have already had to restart the server once, which has a negative impact on our call centre users.

Thanks,

Cause

Product Enhancement Change Request Number 12-1BYX33J

Solution

Message 1

For the benefit of other readers :

The Customer was currently experiencing some Server Request Broker (SRBroker) error behavior, whilst running some specialised Workflow Processes using their Siebel Version 7.7.2.2 product release. Specifically, the SRBroker Components were consuming a large amount of available memory (around 15Gb RAM) causing their SRBrokers to become "maxed out" and the users would then be experiencing some performance challenging error behavior.

Following on from our examination of the Server Request Broker settings, we discovered that their Siebel Object Manager parameter settings had been changed and were different from the ones originally specified by our Expert Services (ES) Division during their PRR (Production Readiness Review). For example: their EAI (Enterprise Application Integration) Object Manager MaxTasks Server parameters were set to 50, whereas originally they had been set to 20. We were also concerned that the Customer was running 100 SRBrokers on one Enterprise Application Server machine, whereby the Siebel recommendation would be to run 1 SRBroker with 100 Max MT Server Tasks instead.

We also suggested that the Customer run with the Siebel "Recycle" Factor for their Object Manager Settings - addtional information can be acquired from reading through Siebel Version 7.7.2.x Bookshelf > Siebel System Administration Guide > Appendix A: Siebel Server Components and Parameters > Generic Parameters > Parameters :

<Continued ...>

Message 2

Recycle Factor. This parameter allows an alternate method to managing resources through the use of a rolling shutdown and restart of component processes. The Siebel Server components, however, do not require the recycling of processes. Use this parameter to remedy your application only if excessive memory usage appears to exist.

The Customer also required some information regarding the use of the Siebel Server Scheduler ? I discovered this information for them :

The Siebel Server Scheduler (SrvrSched) is a Component Definition, and therefore runs as a Component on every Siebel Server. It is a multi-threaded component. However, it is advisable to only run 1 per Siebel Server. The default settings for a multi-threaded component are:

          MaxTasks=20
          MinMTServers=1
          MaxMTServers=1

As such, you will then see that MaxTasks = 1 defined at the Component Definition level for "SrvrSched". This will ensure that 1 process, with 1 Server Task is loaded per Siebel Server. Since it exists as a background component on each Siebel Server which Schedules Siebel Server job execution, details can be then captured by increasing event Log Levels.

Under normal and most circumstances, it is advisable to just leave this alone. As it is internal task that forms part of System Task Management and one of the first processes loaded when the Siebel Server is actually started and is used to spawn the other components.

<Continued ...>

Message 3

I raised Product Enhancement Change Request Number 12-1BYX33J to allow for "monitoring" of these Siebel Server Scheduler (SrvrSched) Component Task Parameter settings. I also raised Documentation Enhancement Change Request Number 12-1C06PMF to have this Siebel Version 7.7.2.x Bookshelf > Siebel System Administration Guide updated with additional information surrounding the use of this Siebel Server Scheduler.

Keywords: SRBroker, Server, Request, Settings, MT, Task, Parameters, Asynchronous, Monitor, Scheduler, Components






Applies to:

Siebel System Software - Version: 7.5.2.214 SIA [16066] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.2.214 [16066] Fin Svcs
Database: Oracle 8.1.7.4
Application Server OS: Microsoft Windows 2000 Server SP 3
Database Server OS: Sun Solaris 2.8

This document was previously published as Siebel SR 38-1094804267.

Symptoms

SBL-EVT-01012, SBL-SVR-00005, SBL-SVR-00029, SBL-SCC-00025, SBL-SVR-01045, SBL-SCM-00018, SBL-SMI-00033, SBL-SRB-00061, SBL-SRB-00041, SBL-GEN-05009, SBL-ADM-02044, SBL-ADM-02049Hello,

I have just finished upgrading from 7.5.2.214 SIA [16066] to 7.5.3 SIA [16157].

Our configuration is:
- 1 Unix server CLSSS22: OS Solaris 2.8 with the Entreprise Server et 1 Siebel Server 'CRMR'
- 1 Windows 2000 Service Pack 4 Server 'xxxSA2048'
- Oracle version 9.2.0.2

When I go on the server admin screens, I can see that the server server 'xxxSA2048' is in status "Echec de la connexion" (connexion failed). If i click on this server, i receive the following error "SBL-ADM-02044: Aucune connexion trouvée sur les serveurs actifs.".

By server manager, i have the following message:
"decibel@clsss22:/appsiebel/siebel/siebsrvr/bin$ srvrmgr /e CRMR /g CLSSS22:2323 /u SADMIN /p SADMIN            
Connected to 1 server(s) out of a total of 2 server(s) in the enterprise
srvrmgr> list server
SBLSRVR_NAME HOST_NAME INSTALL_DIR                 SBLMGR_PID SV_DISP_STATE SBLSRVR_STATE START_TIME           END_TIME SBLSRVR_STATUS                 
------------ --------- -------------------------- ---------- ------------- ------------- ------------------- -------- ------------------------------
CRMR          clsss22    /appsiebel/siebel/siebsrvr 15564       Running        Running        2003-10-07 11:22:27            7.5.3 [16157] LANG_INDEPENDENT
xxxsa2048     xxxsa2048 E:\sea752\siebsrvr                      Connect failed"

Thank you for your help

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers, the 'Connect failed' error was caused by a network problem. The new Windows 2000 Server 'xxxSA2048' (masked) was not declared in the DNS server. After setting the correct value to DNS and restarting the machine, the connection to server was successfully established.

The error messages received were as follows in the Siebel Server Log files.

SBL-SCC-00025; SBL-SVR-00029; SBL-ADM-02049; SBL-ADM-02044; SBL-EVT-01012; SBL-SVR-00005; SBL-SVR-01045; SBL-GEN-05009;SBL-SMI-00033; SBL-SRB-00061; SBL-SRB-00041; SBL-SCM-00018

The following Supportweb Knowledge items were also suggested:

FAQ 1323 which discusses how to troubleshoot error ADM-02044.
FAQ 1187 which discusses how to troubleshoot error ADM-02088.
FAQ 1399 which discusses how to troubleshoot error NET-01003.


-Siebel Technical Support

Keywords: DNS Server, Connect Failed, list server, SBL-SCC-00025, SBL-SVR-00029, SBL-ADM-02049, SBL-ADM-02044, SBL-EVT-01012, SBL-SVR-00005, SBL-SVR-01045, SBL-GEN-05009, SBL-SMI-00033, SBL-SRB-00061, SBL-SRB-00041, SBL-SCM-00018




Applies to:

Siebel CRM - Version: 7.5.3 [100] to 8.1.1.7 [21238] - Release: V7 to V8
Information in this document applies to any platform.
Product Release: V7 (Professional)

Application Server OS: Microsoft Windows 2000 Server SP 4
Database Server OS: Microsoft Windows 2000 Server SP 4

Symptoms

It was reported that there were problems using drag drop functionality in the Siebel application. When the user was trying to save an attached document, the system was displaying the following error message:
Session Warning: The server you are trying to access is either busy or experiencing difficulties. Please close the Web browser, open a new browser window, and try logging in again.
After this error, the user is usually logged out of the application.

The issue was only present in the thin client and could not be reproduced in the dedicated client.
The same error was observed in the thin client using both DB authentication and ADSI authentication.

The following messages were displayed in the SWE logs:
ProcessPluginRequest    ProcessPluginRequestError    1    0    2006-04-18 17:15:22     5116: [SWSE] RPC coming in without a user session

ProcessPluginRequest    ProcessPluginRequestError    1    0    2006-04-18 17:15:22     5116: [SWSE] Failed to obtain a session ID. NOT OK

ProcessPluginRequest    ProcessPluginRequestError    1    0    2006-04-18 17:15:22     5116: [SWSE] Set Error Response (Session: Error: 00065535 Message: NOT OK)


The following error messages may also be seen for the end user or in the logs related to this issue:
SBL-UIF-00401, SBL-SCR-00141, SBL-DAT-00215, SBL-DAT-00712, SBL-SVR-01051, SBL-SCM-00022, SBL-SMI-00033, SBL-NET-01023, SBL-BPR-00125, SBL-BPR-00151

Cause

The cause of this issue was determined to be an underscore "_" character in the naming of the servers.

Solution

The workaround for this issue is to use the IP address of the server instead of the server name.

Document 477993.1  has additional information regarding problems using a dash/hyphen in the Siebel Server Name.
Document 477993.1 was previously referred to as Alert 1067.

References

NOTE:477993.1 - Siebel Server Failures Due to Hyphen Character in Machine Hostname and in the Siebel Server Name



Applies to:

Siebel System Software - Version: 7.8.2.2 [19219] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.8.2.2 [19219]
Database: Oracle 9i
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: Sun Solaris 9

This document was previously published as Siebel SR 38-3035052921.

Symptoms

SBL-SVR-01015, SBL-SVR-01043, SBL-SMI-00033, SBL-NET-01034, SBL-NET-01033, SBL-ADM-01044, SBL-SCB-00015, SBL-SCB-00011Hi,

Each night a cold DB backup is taken on each environment. This is affecting a number of components on the Siebel server:

Transaction Processor
Transaction Merger
Transaction Router
Server Tables Cleanup

These components need to be restarted each morning as the backup is affecting them. I decided to use scripts to shutdown the siebel server 15 mins before backup is taken and another to restart it in the morning. I have tested these script on one environment and this works fine. On another environmnet the shutdown script appears to hang (i.e batch job does not complete). All the parameters are correct as the command would not run otherwise. I have attached the script and the log files at the time it executed (01:45). As you can see from the log file at 06:00 created after the startup script is executed, the server is still shutting down. Can you please inform me what the issue is?

Kind regards

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers:

The customer's script:

D:\sea78\test\siebsrvr\BIN\srvrmgr /g UKGateway /e siebtest /s SiebTest1 /u sadmin /p password /c "shutdown appserver SiebTest1"

In review of the customer's component log files, we could see that there was a problem with one or more components shutting down. As stated in SupportWeb SR 38-1147657941 [Siebel Servers stick in "Shutting down" state], the "shutdown appserver" command issued from the Server manager command-line is a synchronous process, thus the command will block until all tasks in the server have exited. There could be a problem stopping one or more components, caused either by the components themselves, or caused by the synchronous nature of the shutdown process (ie. one component is waiting on a response from another component, or the Siebel server - that may have already been shutdown).

The customer was recommended to use the Windows command, net stop. The net stop command is used as follows:

net stop <service>

For example:

net stop SiebSrvr

Which would stop the service called SiebSrvr.

Assuming you do not have any problem stopping your Siebel Server service using the Windows' Services utility, then you should not experience a problem with using the net stop command to stop the Siebel Server service. You can schedule the command using the Windows command, at.

This information resolved this for the customer.

Regards,







Applies to:

Product Release: V7 (Enterprise)
Version: 7.5.3 [16157]
Database: Microsoft SQL Server 2000 SP3
Application Server OS: Microsoft Windows 2000 Advanced Server
Database Server OS: Microsoft Windows 2003 Server

This document was previously published as Siebel SR 38-2898910561.

Symptoms

We have recently applied the 7.5.3.14 patch to our 7.5.3 installation. We have patched both our DEV and TEST instances.

In our TEST environment only, the only environment with Communications Management enabled, we are seeing new log files for smart answer and SRBroker being created about every couple seconds. This has only been an issue since the application of the 7.5.3.14 patch. The smart answer files show an error of "Smart Response module is not licensed" and the SRBroker files show an error of " [TCPIP-server] recv() failed for sd=2088 (err=10054 | A existing connection was forcibly closed by the remote host (peer).)

GenericLog    GenericError    1    2006-02-03 22:50:53    (smimtses.cpp 18(352) err=2100033 sys=0) SBL-SMI-00033: The client exited without closing the SISNAPI connection"

Do you have any suggestions to resolving this, other than setting the smart answer component to disabled? How can I verify our license contains this module for comm mgmt?

Why are these log files being generated only AFTER applying the patch to the application? it was running with no issues before the patch.

Thanks

Solution

Message 1

For the benefit of others:

After a recent upgrade, the smart answer functionality of communications server seemed to have been disabled. It was later discovered that the customer was not licensed for this functionality. However, the issue became stopping the logging from occurring, for a disabled component.

To ensure logging is inactive for a component:

There are a couple of areas to check, to make sure that logging is no longer active...

First, ensure that the component is completely inactive:

Administration - Server Management > Components > Smart Answer Manager

Please make sure that the component is both offline and Shutdown

Next: Verify the logging event levels...

Administration - Server Configuration > Components > Smart Answer Manager > Events (Tab)

Please make sure that all of the event levels are 1 or zero. 1 is the default, and will only produce log entries for component Errors. 0 will only produce errors for Fatal events. You can also check the other components, such as SRBroker and CommMgr. Specifically, if there are any components where you have increase event logging, please return those to 1.

Best regards,

Siebel Technical Support

Keywords: continuing continuous logging wont stop repeating logs

 

 


No comments:

Post a Comment