Applies to:Siebel Tools - Version 7.7.2 SIA  to 220.127.116.11 SIA [Release V7 to V8]
z*OBSOLETE: Microsoft Windows Server 2003
Database: IBM DB2 8.1 FixPack 8
Application Server OS: Microsoft Windows 2003 Server
Database Server OS: Microsoft Windows 2003 Server
This document was previously published as Siebel SR 38-3053350591.
Java application has been used to import xml files into Siebel calling the EAI Adapter. However, on large files, a timeout resulting in the following error is thrown.
OMRPC Request 2 on connection 24e4 was abandoned after 600250 ms because it timed out. (SBL-JCA-317)
After reading other service requests, I created a siebel.properties file with the following values:
siebel.conmgr.txtimeout = 3900
siebel.conmgr.poolsize = 5
siebel.conmgr.sesstimeout = 3000000
siebel.conmgr.retry = 5
siebel.conmgr.jce = 1
I put the following sample code into the java program and the value returned was correct.
Properties properties = new Properties();
String propStr = properties.getProperty("siebel.conmgr.txtimeout");
System.out.println("Value of property = " + propStr);
catch (IOException e)
System.out.println("Error to read properties file " + e.getMessage());
However, as we understand from other requests, the file only has to exist in the classpath for it to be utilised by the adapter. How do I examine if the adapter is using the value in the siebel.properties file or using the default from the Object Manager?
Reasons for the behavior
The Java 1.4.2 virtual machine uses the -jar command line option to start a Java program from within a JAR file. In this case, as per the Java 1.4.2 documentation, "the JAR file is the source of all user classes, and other user class path settings are ignored."
Since the siebel.properties file must be located in the Java classpath it is subject to the classpath rules of the Java VM.
(Side note: As this issue was caused by the classpath search behavior of the Java VM which is a third-party component, no change request was raised.)
Additional keywords: class path, databean, jvm
Applies to:Siebel Tools - Version SCS 6.0.3  and later
Information in this document applies to any platform.
A Java program is written to use EAI Siebel Adapter to export records into XML files. It is noticed the following error every Monday of the week. The export runs again after executing again after it errors out.
the following error occurs.
<Major No.>256</Major No.><Minor No.>8236</Minor No.><Message>OMRPC Request 1166 on connection 72232 was abandoned after 270250 ms because it timed out. (SBL-JCA-317) </Message><DetailedMessage>Unknown<DetailedMessage>
The issue cannot be reproduced at will but it occurs on every Monday of the week.
Due to this issue, the export has to be re-run whenever this error is encountered.
"siebel.conmgr.txtimeout" property is not set. However, as tested, this is not true in version 18.104.22.168. The timeout appears to be near to 4.5 minutes (270250 ms). In version 8, the default transaction time out is 10 minutes. As such, a documentation defect (Bug No: 11802093) has been logged to address this on Siebel Bookshelf. Please use "siebel.properties" file to set to the desired transaction timeout.
BUG:11802093 - DEFAULT VALUE FOR SIEBEL.CONMGR.TXTIMEOUT IS NOT 10 MIN FOR V7.8
Applies to:Siebel System Software - Version 22.214.171.124 SIA  and later
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 126.96.36.199  Com/Med
Database: Oracle 188.8.131.52
Application Server OS: Sun Solaris 9
Database Server OS: Sun Solaris 8
This document was previously published as Siebel SR 38-3360281273.
We are experiencing two unexpected behaviors when attempting to log into eCommunications:
1) The Login Page is not displayed. "Page Cannot Be Displayed" error after about 10 minutes.
2) The Login Page is displayed, but "Page Cannot Be Displayed" error after attempting to log in.
We are able to access the database via a Dedicated Client and can use the ServerManager commands.
We have already tried bypassing all Load Balancers and the LDAP Server unsuccessfully.
We are currently getting JCA Connection errors from Portal to Siebel.
We are seeing excessive CPU for Kernal and IOWait.
We are seeing some discrepancies with the mounted file system.
After removing the Anonymous User *.spf file from the userpref directory, we started getting the Home Page.
However, the system attempted to create the new file but it has 0 byte, and the file name convention is different, for example, <username>&<application>.spf_<hostname>_14084_13.
This seems to be related to file access rights, but we made everything 777 and still get the same error.
We know that this UNIX machine had some problems with this mount point after a power outage, but we do not know the details.
We turned up logging for eComm and SCBroker and the logs stop just prior to getting access the UserPref file.
For eCustomer, it looks like we can connect via JCA for the initial request (GetMDN), but then for the GetHierarchy we get an error and lose the JCA connection:
[SIEBEL ERROR] [2007-05-25 12:25:55.892] [SiebelConnection(1230636829)] Complex Account Hierarchy - Portal Services.GetHierarchyByUser FAILED on Connection (siebel.tcpip.none.none://<hostname>:2321/esblr/eCustomerCMEObjMgr_enu/!3.6e01.4893.46570dcc, INT_PORTAL with message <com.siebel.om.sisnapi.RequestException>
<Error><ErrorCode>8236</ErrorCode> <ErrMsg>OMRPC Request 4 on connection 18579 was abandoned after 60070 ms because it timed out. (SBL-JCA-317) </ErrMsg></Error>
Users are getting “This page cannot be displayed – Cannot find server or DNS error” error message when trying to load the login page or after providing username and password.
After deleting the User Preferences File, this behavior was resolved, but the new user preference file was created with zero byte.
We have ruled out the possibility of this behavior being related to the situation described in Alert 1025: Siebel Server Components That Read or Write to Files on Solaris May Encounter Fopen() Behaviors.
We have checked all Operating System user limits.
After further investigation, customer found out that a lockd daemon process was not running on the server where the shared Siebel File System resides after the power outage.
All the other Siebel Servers have NFS mounts pointing to this server to access the shared File System.
Once lockd was started on that server, the behavior was no longer observed.
The following Service Requests helped troubleshooting this behavior:
- Doc ID 504354.1: Unable to connect to Public Sector with SisnSockError
- Doc ID 495979.1: Web client hangs when trying to login
Applies to:Siebel Finance Sales - Version: 184.108.40.206 SIA  to 8.1 SIA  - Release: V8 to V8
Information in this document applies to any platform.
During this step the ADM Management Server sits without anything happening. Eventually the management server times out.
The management server hangs after the Activation step. All the previous steps (load, create, and copy) are successful. SADMIN has the system administrators authorities in the target environment.
Log from targeting ADM agent:
2009-01-26 16:43:20 -0500
FileMBean INFO 2009-01-26 16:43:21 Results from action 'BACKUP':
2009-01-26 16:44:49 -0500
FileMBean INFO 2009-01-26 16:44:50 Copying from source file '\\D-OPT8-DOCN1\ADMShare\lei_web_02\file\AppServer\webmaster\Images\ENU\globe77_temp.gif'.
FileMBean INFO 2009-01-26 16:44:50 Deploying to destination file '\\D7-OPT8-GTWN1\upload\Images\ENU\globe77_temp.gif'.
FileMBean INFO 2009-01-26 16:44:51 Results from action 'DEPLOY_COPY':
2009-01-26 16:51:21 -0500 FileMBean SEVERE 2009-01-26 17:01:42 OMRPC Request 5 on connection 2b0000a was abandoned after 600070 ms because it timed out.(SBL-JCA-00317)
When running the activate command, sync mode is the default when no mode is specified:
deploy_ES_SIA activate sadmin sadmin abs_web_02
This same hanging behavior can occur with the deploy copy command in sync mode.
In this case, the customer running the deploy copy in sync mode runs fine without hanging.
deploy_ES_SIA activate sadmin sadmin abc_web_02 -async
This runs successfully.
In async mode, the command prompt does not wait for the command to finish: the prompt returns right away and the task is queued to be executed.
It is necessary to run status_detail to check on the status of the queued task:
deploy_ES_SIA status_detail sadmin sadmin abc_web_02