SBL-SRB-00041: Could not send a SISNAPI hello message after connecting to the component



Applies to:


Siebel System Software - Version 7.5.2.100 SIA [15252] to 8.1.1.4 SIA [21225] [Release V7 to V8]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.5.2.100 [15252] Life Sci

Database: Oracle 8.1.7

Application Server OS: Microsoft Windows 2000 Advanced Server SP 2

Database Server OS: Microsoft Windows 2000 Advanced Server SP 2



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



CHECKED FOR RELEVANCE ON 1-FEB-2013







Symptoms


SBL-SMI-00033, SBL-SRB-00041, SBL-NET-01034



Typical error is as follows:

2021 2003-06-04 00:30:05
2003-06-04 00:30:05 +0100 00000042 001 ffff 0001 09 SRBroker 36931 548
592 E:\sea752\siebsrvr\log\SRBroker_36931.log 7.5.2.102 [15255] ENUENU
GenericLog    GenericError    1    2003-06-04
00:30:05    (smimtses.cpp 18(352) err=2100033 sys=0) SMI-00033: The
client exited without closing the SISNAPI connection
TaskCfgExit    TaskParamsAtExit    1    2003-06-04
00:30:05    ***********Dumping Parameters for the current task because
of errors**********

In addition to this SRBroker error:

2021
2003-05-29 14:46:49 2003-05-29 14:46:49 +0100 00000046 001 ffff 0001 09
SRBroker 20550 2484 2508 E:\sea752\siebsrvr\log\SRBroker_20550.log
7.5.2.102 [15255] ENUENU
GenericLog    GenericError    1    2003-05-29
14:46:49    (srbthrd.cpp 44(2445) err=1801033 sys=0) NET-01033: The
SISNAPI handshake timed out, the Siebel Service may not be running
GenericLog    GenericError    1    2003-05-29
14:46:49    (srbthrd.cpp 44(2445) err=5700041 sys=0) SRB-00041: can't
do SISNAPI handshake
GenericLog    GenericError    1    2003-05-29
14:46:49    (srbthrd.cpp 44(2766) err=5700041 sys=0) SRB-00041: can't do
SISNAPI handshake
GenericLog    GenericError    1    2003-05-29
14:46:49    (srbthrd.cpp 44(1444) err=5700041 sys=0) SRB-00041: can't do
SISNAPI handshake
GenericLog    GenericError    1    2003-05-29
14:46:49    (smimtsh.cpp 25(307) err=5700041 sys=0) SRB-00041: can't do
SISNAPI handshake
TaskCfgExit    TaskParamsAtExit    1    2003-05-29
14:46:49    ***********Dumping Parameters for the current task because
of errors**********




Cause


Not an issue.



Solution


For the benefit of reader,

Customer has seen the following intermittent error messages in their SRBroker log files:


GenericLog    GenericError    1    2003-06-04 00:30:05    (smimtses.cpp
18(352) err=2100033 sys=0) SMI-00033: The client exited without closing
the SISNAPI connection

GenericLog    GenericError    1    2003-05-29 14:46:49    (srbthrd.cpp
44(2445) err=1801033 sys=0) NET-01033: The SISNAPI handshake timed out,
the Siebel Service may not be running

GenericLog    GenericError    1    2003-05-29 14:46:49    (srbthrd.cpp
44(2445) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake

GenericLog    GenericError    1    2003-05-29 14:46:49    (srbthrd.cpp
44(2766) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake

GenericLog    GenericError    1    2003-05-29 14:46:49    (srbthrd.cpp
44(1444) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake

GenericLog    GenericError    1    2003-05-29 14:46:49    (smimtsh.cpp
25(307) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake


After increasing the logging event for SRBroker, we have figured out
that these errors resulted from server shuting down, and can be ignored.
In customer's environment, they have three siebel servers.


Because SRB communicates to all other SRBs on other servers, and
communicates to SRP on the same server, when one of the SRB exits, the
up SRB will normally log the corresponding SISNAPI errors. In the same
way, If on the same server, when SRP exits before SRB , such as server
shuting down, SRB also logs the corresponding SISNAPI error.

Search Keyword: SRBroker, SISNAPI.








Applies to:


Siebel Financial Services CRM - Version 7.8.2.6 SIA [19230] and later
HP-UX PA-RISC (32-bit)
HP-UX PA-RISC (64-bit)
HP-UX Itanium
HP-UX Itanium (32-bit)

One or more Siebel components become unavailable, even if their logs show they are running



SRBRoker log shows errors like

SBL-SRB-00041: Could not send a SISNAPI hello message







Symptoms


In this particular case, the FSMSrvr component registered with port 49179 when the Siebel Server started up


netstat -an | grep 49179


showed


tcp        0      0  127.0.0.1.49179        *.*                     LISTEN tcp        0      0  *.49179                *.*                     LISTEN tcp        0      0  127.0.0.1.49179        127.0.0.1.924           ESTABLISHED tcp        0      0  127.0.0.1.924          127.0.0.1.49179         ESTABLISHED

The Siebel component binds with * (bold),


the binds to localhost (127.0.0.1) are from other software using the same port - in this case, HP Open View.


SRBroker requests don't reach the Siebel component, in this case FSMSrvr.



Note that this is not limited to any specific component name - it can
affect any Siebel Component whose port number from the enterprise log is
used by a different process; another customer for example reported the
same problem for WfProcBatchMgr that suddenly stopped processing
(repeating component) requests.



Cause


HP Open View and also HP WBEM services are using ports already in use by the Siebel Server, leading to a port conflict.


With the Itanium release of HP-UX there was a management utility introduced called

HP-UX Web-Based Enterprise Management (WBEM) Services. This tool is
allocating ports in the same range as the siebel processes, starting at
port 49152. However they bind these daemon processes

named "cimprovagt" only to the loopback adapter which is causing the collision.


Siebel Applications use


SO_REUSEADDR


when opening ports - this is done on purpose to avoid long delays
waiting for a timeout when stopping and starting the Siebel Server


This allows HP Open View binding with localhost (even though the
Siebel Port is already opened and used by the Siebel Application)


and the use of the same port (for different purposes) by two
different applications causes the Siebel component no longer to get its
requests.






Solution


As a quick workaround (that needs to be repeated after every re-boot)




1. Run netstat -an and identify which
root processes are blocking the siebel component ports as described in
the "Symptoms" section.



2. Also execute lsof -i tcp |grep <port number> to identify more root processes blocking siebel component ports as above.



3. Kill the root processes identified this way.


For a permanent solution,




please invoke HP-UX / Open View support,


asking them how Open View or WBEM can be configured to use a port
range that does not conflict with the Siebel Server (which starts using
ports from 49152),


e.g. 49300 and above.


http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1216221381645+28353475&threadId=646982


has more information, put assistance how to configure this would need to come from HP-UX support


HP-UX uses the "ndd" utility program to change tunable IP stack
parameters.  The ephemeral ports on HP-UX can be tuned individually for
both TCP and UDP, so there are really two separate ephemeral port
ranges.  HP-UX also provides options to change the privileged port range
(ports only processes running with superuser privileges can use).


The good news is that HP-UX uses our recommended port range (49152
through 65535) so it is unlikely you will need to change the range from
the default values.


The example below shows how to query the existing values for the TCP
ephemeral ports, and change the range to 50001 through 61000:


# /usr/bin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port

49152


65535

# /usr/bin/ndd -set /dev/tcp tcp_smallest_anon_port 50001

# /usr/bin/ndd -set /dev/tcp tcp_largest_anon_port 61000

# /usr/bin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port

50001


61000

Note that if you change the range values, you must do it each time the system boots."





If this cannot be done on the Open View Side,

you may choose to set static ports for every single Siebel Component to avoid port conflicts here.





Keywords (desperate attempt to show this document before the many MR release notes in the knowledge search):



HP-UX port blocked HP-UX PORT USED


hp-ux blocked port


hp-ux blocked port


'hp-ux blocked port'


"hp-ux blocked port"


hp-ux blocked port Siebel


hp-ux blocked port


hp-ux blocked port


'hp-ux blocked port'


"hp-ux blocked port"


hp-ux blocked port Siebel








Applies to:


Siebel System Software - Version 7.8.2 [19213] to 8.2.2.2 SIA[23016] [Release V7 to V8]
Information in this document applies to any platform.

Error Message Area:Server Request Broker - SRB

Version:Siebel 7.8

***Checked for relevance on 27-Feb-2013***





Purpose


This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-SRB-00041: Could not send a
SISNAPI hello message after connecting to the component.



Scope


This document is informational and intended for any user.



Details



Explanation


Could not send hello message to a remote SRB or local batch mode components or local SRProc.
The components may not have been running after the connection was instantiated.



Corrective Action


Check to make sure that:
1) Remote SRB is still running,
2) Batch mode components are still active,
3) Local SRProc is still running.








Applies to:


Siebel System Software - Version: 7.5.3 [16157] and later   [Release: V7 and later ]
Information in this document applies to any platform.

Error Message Area:Server Request Broker - SRB

Version:Siebel 7.5.3



Purpose


This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-SRB-00041: can't do SISNAPI
handshake



Scope


This document is informational and intended for any user.



SBL-SRB-00041: can't do SISNAPI handshake



Explanation


Could not send hello message to a remote SRB or local batch mode components or local SRProc.
The components may not have been running after the connection was instantiated.



Corrective Action


Check to make sure that:
1) Remote SRB is still running,
2) Batch mode components are still active,
3) Local SRProc is still running.








תגובות

הוסף רשומת תגובה

פוסטים פופולריים מהבלוג הזה

Profile Attributes and Open UI

תמונה
Yes, Profile Attributes! As the ever attentive, up-to-date Siebel CRM expert that you are when you read this, you know that in Siebel Open UI (since version 15), it is no longer allowed/supported to  set  Profile Attributes from browser-side script. But  getting  them is not a problem, since the  GetProfileAttr  function works perfectly fine. Recently I found a few vanilla Profile Attributes that came quite handy in my work in Open UI JavaScript: Navigation Type : stores the navigation type such as "NAVIGATION_TAB" ActiveViewName : does what it says on the tin IsOpenUI : returns "1" when the application runs in Open UI Is SUI Theme : when "TRUE", the application theme is Synergy (aka SUI) Position:  returns the currently active position Primary Responsibility Name : guess what this one is… Profile Image : returns the URL of the user's profile image Org.Name : returns the name of the user's organization Here's a sample line of ...
המשך לקרוא

SBL-BPR-00191: The rowId of the active row of the primary buscomp '%1', '%2', does not match the Primary Id

Applies to: Product Release: V7 (Enterprise) Version: 7.5.3 [16157] ESN Database: Oracle 9.2.0.2 Application Server OS: Microsoft Windows 2000 Server SP 3 Database Server OS: Microsoft Windows 2000 Server SP 3 This document was previously published as Siebel SR 38-1386997031. Symptoms SBL-BPR-00191 We have a error with a workflow. This WF is excuted by policy when a particular activity is closed. The WF Business Object is 'Action'. Inside this WF, there is a subprocess that invokes a Business Service that creates a new activity. In a second subprocess, the region Id of this new activity is updated using the standar update method funcionality of Siebel workflow process. Error processing Siebel Operation for: Business Object 'Action' Business Component 'Action' Primary Id ''1-5NEI6' Operation 'Insert'(SBL-BPR-00100) -- The rowId of the active row of the primary buscomp 'Action', '1-4SNCV', does not match the Prima...
המשך לקרוא

SBL-SVC-00150

Applies to: Siebel CRM - 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: IBM DB2/UDB 7.2 Application Server OS: Microsoft Windows 2000 Advanced Server SP 2 Database Server OS: IBM AIX 4.3.3 This document was previously published as Siebel SR 38-1153677971. Symptoms SBL-SVC-00150In callcenter (development environment) Group News administration > All News, when the ‘Status’ field of a news story is changed from ‘Submitted’ to ‘Completed’, the following error pops up. You cannot change the current field’s value from ‘Submitted’ to ‘Completed’. Rule validation failed: ‘[Total Approvers] = 0’ (SBL-SVC-00150) When the status field of a news story is changed from ‘Submitted’ to ‘Pending Approval’, the following error pops up. You cannot change the current field’s value from ‘Submitted’ to ‘Pending Approval’. R...
המשך לקרוא