SBL-SRB-00051: Could not find connection to the component

Applies to:

Siebel System Software - Version: 8.1 [21039] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Error Message Area:Server Request Broker - SRB

Version:Siebel 8.1

Purpose

This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-SRB-00051: Could not find
connection to the component.

Scope

This document is informational and intended for any user.

SBL-SRB-00051: Could not find connection to the component.

Explanation

There is no connection to the component. The component may be down.

Corrective Action

Check to make sure that:

1. SRBoker is still running.


2. Batch mode components are still active.


3. Try restarting the component to re-establish the connection.

Applies to:

Product Release: V7 (Enterprise)

Version: 7.8.2 [19213] Pub Sect

Database: IBM DB2 for zOS and OS/390 v8

Application Server OS: IBM AIX 5L 5.2

Database Server OS: IBM zOS



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

Symptoms

SBL-SRB-00051When we are running a workflow process, we do external web service call to an external system.
if this is running one occurrence it runs fine, however if we run 15 concurrently we get the
following error.

SBL-SRB-00051: no connection for the component


I have attached
the logs for you info.

Solution

Message 1

Customer was testing "EAI HTTP Transport" connecting to an SSL enabled webserver.

Numerous hangs were encountered when doing performance/stress testing.

This only occured when the webserver was using SSL.



Using the "pstack.sh" script(available Troubleshooting Steps 30) against the hung process

it could be seen that a thread was actually crashing, but had caused a hang.



Following stack was seen:



in pth_spinlock._global_lock_common [/usr/lib/libpthread.a] at 0xd011029c ($t94)

0xd011029c (_global_lock_common+0x35c) 80410014        lwz   r2,0x14(r1)

pth_spinlock._global_lock_common(??, ??, ??) at 0xd011029c

malloc_common.__malloc_prefork_lock_common() at 0xd02f7df0

malloc_common.__malloc_prefork_lock() at 0xd02f7208

fork.f_fork() at 0xd033ec90

mwsystem__FPCc() at 0xd934a940

system_append__FPcP4FILET1() at 0xd934b184

MwPrintProcOSInfo__Fi() at 0xd934afc4

MwPrintCurProcOsInfo__Fv() at 0xd934af0c

MwPrintProcInfo__FiPc() at 0xd934ab64

MwAbort() at 0xd928ae98

InvokeUnhandledExceptionFilter(SEH_THREAD_BLOCK*)() at





This turned out to be the behaviour described in "Alert 1198: Object
Manager Hang Behaviors on UNIX Platforms Due to Calls to Malloc Memory
Management Function in the Crash Handler Code "



The actual "fork" statment is generating the malloc, CR #10642640 was raised to track this.



[cont]

Message 2

This hanging behaviour means that memory corruption has taken place.

When setting the MWNO_SIGNAL_CATCHING=TRUE, the processes started to crash.

The callstacks were random , but always ended in a memory management statement such as malloc.





This was reproduced in Oracle Technical Support and Change Request 10521329

was logged to address this product defect.