SBL-ADM-01011: INTERNAL: bad request type

Applies to:

Siebel System Software - Version: 7.8.2.3 [19221] - Release: V7

Information in this document applies to any platform.

Goal

What could cause the error
SBL-ADM-01011
INTERNAL: bad request type

when invoking srvrmgr

(after just deploying a new .srf)?

Solution

For the benefit of other readers: Change request

12-IZ0GW2

is logged to have the error

SBL-ADM-01011
INTERNAL: bad request type

documented and its root causes explained.

Currently, there is no further information available.

The customer confirmed that a new compilation of the .srf made the error go away, so it seems caused by a corrupt .srf.

srvrmgr itself does NOT use the .srf, but if object managers fail to start because of a corrupt .srf, this will affect srvrmgr as well.

References

BUG:12-IZ0GW2 - DOCUMENTATION REQUEST FOR ADM-01011: INTERNAL: BAD REQUEST TYPE

Applies to:

Product Release: V7 (Enterprise)
Version: 7.7.1 [18306]
Database: Oracle 9i
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8

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

Symptoms

SBL-SRB-00041, SBL-NET-01033, SBL-ADM-01011, SBL-SCB-00013

We are using a third party hardware load balancer (Radware). We are getting repeated error in our SCBroker log:


1021 2004-11-24 11:18:47 0000-00-00 00:00:00 -0500 00000000 001 ffff 0001 09 SCBroker 35848 24894 1 /export/apps/siebel/siebel7.7/siebsrvr/enterprises/siebel/labser21/log/SCBroker_35848.log 7.7.1 [18306] ENU
GenericLog    GenericError    1    0    2004-11-24 11:18:47    (scbcomp.cpp (373) err=7100013 sys=1) SBL-SCB-00013: Client disconnected before connection could be processed.
GenericLog    GenericError    1    0    2004-11-24 11:18:47    (scbcomp.cpp (235) err=7100013 sys=0) SBL-SCB-00013: Client disconnected before connection could be processed.

Please advise. Thanks. I will attach some files for ref.
Son

Solution

Message 1

Son,

Thank you for your Service Request update.

I have done further research on the error message you are encountering in the SCBroker log file "SBL-SCB-00013: Client disconnected before connection could be processed" and I found that this is only an informational message and there is no reason to worry about it. You have also mentioned that the disk problem was fixed, the load balancer is round-robin load balance correctly and I assume that currently your Siebel environment is working properly.

Please let me know your current status, whether this problem needs further attention, if you have further questions, etc. and if not, if I may now conclude the work on this Service Request.

Kind regards from
Arianne Popa, Siebel Technical Support

Message 2

Arianne:
Thanks for the info. Is there a way to suppress these errors? The log files are filling up very fast and taking up lot of space. Also, it will be difficult to wade thru these ignorable errors to find the revelant errors if there are any.

Thanks
Son

Message 3

Son,

Regarding the error messages you are encountering in the SCBroker log file "SBL-SCB-00013: Client disconnected before connection could be processed", I have logged the Change Request 12-S8XTCV (SCBroker errors in the log file: SBL-SCB-00013) in order to have these errors appearing only when the log level is set to 4 or 5 for the SCBroker component since a benign message should only appear under high event logging.

I have associated this Service Request to the above-mentioned Product Defect. Please note that in general, when a product defect is logged, it is reviewed, prioritized, and then potentially fixed in a future release.

In order to manage the size of the log file of SCBroker component I would like to suggest you referring to the "FAQ 1939: How Can Users Manage the Size of the Siebel Log Files?” You will find there information on how you would be able to specify a max log size. When the log file reaches that size, the process closes the file and opens a new one. Using a script, you can open the closed file and “clean” it of these messages. That’s more of a workaround, but it helps keep the logs “clean”.