Applies to:Siebel System Software - Version: 188.8.131.52 SIA  and later [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 184.108.40.206  Auto
Database: Oracle 220.127.116.11
Application Server OS: Sun Solaris 2.8
Database Server OS: Sun Solaris 2.8
This document was previously published as Siebel SR 38-3289921981.
SymptomsSBL-DAT-00144, SBL-EXL-00145, SBL-DAT-00306, SBL-DAT-00315, SBL-DAT-00322, SBL-DAT-00501, SBL-OSD-00204, SBL-SVR-04000, SBL-SVR-01004, SBL-SMI-00034, SBL-SMI-00126, SBL-GEN-09103, SBL-NET-01023, SBL-NET-01201, SBL-NET-01204Our thin clients are presenting error "page can not be displayed” after loggin and doing
We first thought this is because of the SRF, so we have changed the SRF also. But still the same error persists.
I am attaching the log files of the Web server and Siebel eAutomotive object manager.
Some of the errors from the log files are:
SBL-NET-01204: Internal: recv() failed: Connection timed out
SBL-SMI-00034: Internal: Error (null) reading a message from the client
[SWSE] New anon session open failed
SWSE] Could not get an anon session...PROBLEM
[SWSE] after the timeout/broken anonymous connection impersonate failed. Could not open repository file '%1'.\n\nFile does not exist or may be in use by another process?
We already tried by recycling the whole environment also.
Message 1For the benefit of other readers:
After extensive troubleshooting with Resonate environment variables, Resonate password variables in Unix OS and comparing errors in the web server and OM logs, customer was able to identify the server which was presenting the behavior.
Customer had three load balancers in the environment (A, B, C). Due to some activities they were not using the C load balancer. When shutting down the A LB, where only B LB was running, the thin client worked properly without any issue.
When we shut down B and put only A LB up. At that time started getting same error for the thin client.
Customer resolved the issue by removing the defecting node from Resonate and added it back.
It also found that CFGClientRootDir for the defective node was set to %SIEBEL_ROOT% while searching Siebns.dat. This value was also changed.
Thank you and best reagrds,
Applies to:Siebel System Software - Version: 18.104.22.168  and later [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Professional)
Version: 22.214.171.124 
Database: IBM DB2 8.1
Application Server OS: Microsoft Windows 2000 Advanced Server SP 4
Database Server OS: IBM AIX 5L 5.1
This document was previously published as Siebel SR 38-3200626371.
SymptomsSBL-SMI-00034Recently, we began to notice that Siebel Server Scheduler was starting up and failing every minute. Since this time it has never gone away and the Siebel Server Scheduler component appears to start/fail every minute indefinitely. We are unsure of the impact of this component failing.
BEFORE 3:52PM, 10/26/2006 we would receive only this message and only when we had just restarted the environment:
ServerLog ProcessCreate 1 2006-10-25 09:26:01 Created server process (OS pid = 5124) for Siebel Server Scheduler with task id 77975
AFTER 3:52PM, 10/26/2006 we began getting the above message but with an error directly after it and it would occur every minute:
ServerLog ProcessCreate 1 2006-11-11 04:30:53 Created server process (OS pid = 4776) for Siebel Server Scheduler with task id 50426ServerLog
ProcessExit 1 2006-11-11 04:30:53 <NoCompName> 50426
SBL-SMI-00034 Process exited with error - Internal: Error %1 reading a message from the client
Note: These errors are coming from the Enteprise log on one of our Siebel servers.
To help trouble-shooting, I have attatched the following files: 1) A before and after Enterprise log. 2) A before and after siebns.dat file. 3) A few samples of the SiebSrvr.logs that get created when the Siebel Server Schedule is failing.
Questions: 1) Could you provide more background on what the Siebel Server Scheduler does? Note: we looked at various documentation and only got a very short explaination. 2) What is the impact of this component failing? 3) Do you have any ideas what would have caused this behaivor?
Please let me know what other information I can provide. Thanks for your help and cooperation.
Message 1**For the benefit of others***
A number of questions were posed in relation to the Siebel Server Scheduler:
(1) Could you provide more background [information] on what the Siebel Server Scheduler does?
(2) What is the impact of this component failing?
(3) Do you have any ideas what would have caused this behaviour?
The Siebel Enterprise log also contained a number of errors relating to this component:
ServerLog ProcessCreate 1 2006-11-11 05:01:31 Created server process (OS pid = 3276) for Siebel Server Scheduler with task id 50901
ServerLog ProcessExit 1 2006-11-11 05:01:31 <NoCompName> 50901 SBL-SMI-00034 Process exited with error - Internal: Error %1 reading a message from the client
In response to the questions posed...
The “Siebel Server Scheduler” is a background component responsible for Server job execution.
This pre-configured component does not appear as a job that can be configured under the ‘System Administration’ views even though it forms part of the ‘System Management’ component group.
Note, the Siebel Server Scheduler process runs (only becomes “active”) every time a Server needs to fork one of the following processes: siebproc, siebprocmw, siebmtsh, and siebmtshmw processes.
Message 2Important to note, still, is that the type of process/shell that gets started depends on the mode of an associated component (interactive, background, batch) and whether or not an Objected Manager is involved and Multi-threaded.
(You may already be aware that the siebproc is used for server mode components, while siebmtsh is used for forking off multi-threaded batch mode components as well as multi threaded sessions, for instance).
On a further note, before spawning a new process, the scheduler only knows the process type has to come from this list (siebproc, siebprocmw, siebmtsh or siebmtshmw) and nothing more.
That, the component running, at this point in time, only has the identity of the Siebel Server Scheduler should thus account for the error sometimes seen in a Siebel Server enterprise log.
It is only after the Scheduler actually reads the message sent on by a Siebel Server that it acquires ‘knowledge’ about the component it needs to startup, and subsequently loads the same.
With respect to last question, although it is difficult to determine the breakpoint, in this instance, without the benefit of additional logs, please note that the Siebel Server Scheduler could just have easily been called into action, given the following scenarios:
(a) asynchronous requests are processed - repeating component(s), say;
(b) when additional object manager processes to service Client-requests
Applies to:Product Release: V7 (Enterprise)
Version: 126.96.36.199 
Database: Oracle 9i
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8
This document was previously published as Siebel SR 38-1130570961.
We have installed the eService across the Firewall and it is not working.
The ports are opened bi-directionally i.e 2320 and 48090 for object manager eService and other 47000 - 48000 ports are opened on the firewall.
We have installed the Iplanet ws 6sp2 and Siebel 188.8.131.52 eappweb software and all the virtual directories are created properly.
The application server is inside the firewall and the application is running and can be invoked from inside the firewall as it is running from another web server.
So please help. I wil lattach some log files found on the DMZ server install under SWSE/bin and SWSE/log locations.
Message 1Issue : Unable to connect to eservice across a firewall even when all ports above 49000 are open
NOTE: If a firewall is used then Siebel STRONGLY recommends using Resonate. This is documented in Bookshelf.
In this scenario, Resonate was not used, so all ports above 49000 need to be open for the Siebel Object Managers, along with port 2320. Even after doing this eservice was not able to connect across the firewall.
The name of the HOST inside the firewall which had the Siebel Application Server was engit28.central and the same was used in the ConnectString for eservice_enu in eapps.cfg.
Following tests were done to ensure that the ports were indeed open.
From the web server machine outside the firewall we issued the following command
telnet <engit28.central>:2320 and it connected.
telnet <engit28.centra>:<port for esrevice OM determined by looking at the enterprise log> and it was successful.
After further investigation, we ran the following command from srvrmgr connected to the siebel server
change paramter host="engit28.central"
After this we re started the processes and it worked. The reason is that the host name of the sun box which was inside the firewall and had the siebel server, was engit28.central but the siebel server parameter called HOST had the value of engit28. This was verified by looking at the siebns.dat.
Post a Comment