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.