Jolt client vs. jolt connection pooling

We are porting our app to weblogic. We are current users of jolt but since we weren't
using weblogic
we are currently using jolt client out of the app server. We are examining the merits
of converting to use
the jolt connection pool.
I have been told that jolt client is multi-threaded so the question is: if we convert
to jolt connection pooling
will we see a performance improvement, and if so, why? Or is the advantage purely
from an administrative
standpoint, and if so, what are the advantages there?

Connections are resources that the application uses and a fewer connections can be used by multiple threads if the threads are not always busy with the database activity only, and are doing other work too. This sharing (pooling) can be implemented by the application or the application can leverage the connection pooling features offered by OCI/OCCI (recommended).
Be aware of connections vs sessions and sharing them (refer to :
OCI Programming Advanced Topics
OCCIConnectionPool is to pool connections and OCCIStatelessConnectionPool is to pool sessions. Please see the differences in the above link and apply as appropriate.

Similar Messages

Jolt Client Library Access to Queue Information?

Hi,
I'm writing a load balancer healthcheck for a PeopleSoft system. At present I have an http servlet running on Weblogic 10.3.4 which uses jolt client libraries (jolt.jar, joltwls.jar, joltjse.jar) to connect to the PeopleSoft app running on Tuxedo 10.3. I'm able to create a session / transactions etc but am wondering if I can get tuxedo client, server and queue information which may help to base an intelligent load balancing algorithm on. Is this possible or do you need to interrogate a process running local on the Tuxedo server? Ideally I'd be hoping for information similar to the following which was generated using the PeopleSoft application server tool psadmin...
> Prog Name
Queue Name Grp Name
ID RqDone Load Done Current Service
BBL
224049
cs9appp+
0
491
24550 ( IDLE )
PSMONITORSRV   MONITOR
MONITOR
1
0
0 ( IDLE )
PSDBGSRV
DBGQ
DBGSRV
1
0
0 ( IDLE )
PSAPPSRV
APPQ
APPSRV
1
6
300 ( IDLE )
PSWATCHSRV
WATCH
WATCH
1
0
0 ( IDLE )
PSAPPSRV
APPQ
APPSRV
2
6
300 ( IDLE )
PSSUBDSP
SUBDQ_dflt PUBSUB
300
0
0 ( IDLE )
PSSUBHND
SUBHQ_dflt PUBSUB
301
0
0 ( IDLE )
WSL
00001.00020 BASE
20
0
0 ( IDLE )
PSBRKDSP
BRKDQ_dflt PUBSUB
100
0
0 ( IDLE )
PSSAMSRV
SAMQ
APPSRV
100
0
0 ( IDLE )
PSBRKHND
BRKHQ_dflt PUBSUB
101
0
0 ( IDLE )
PSSAMSRV
SAMQ
APPSRV
101
0
0 ( IDLE )
JREPSVR
00094.00250 JREPGRP
250
5
250 ( IDLE )
JSL
00095.00200 JSLGRP
200
0
0 ( IDLE )
PSPUBDSP
PUBDQ_dflt PUBSUB
200
0
0 ( IDLE )
PSPUBHND
PUBHQ_dflt PUBSUB
201
0
0 ( IDLE )
> Prog Name
Queue Name # Serve Wk Queued # Queued Ave. Len
Machine
PSAPPSRV
APPQ
2
0
- cs9apppj1+
PSBRKHND
BRKHQ_dflt
1
0
- cs9apppj1+
PSSUBHND
SUBHQ_dflt
1
0
- cs9apppj1+
PSPUBHND
PUBHQ_dflt
1
0
- cs9apppj1+
BBL
224049
1
0
- cs9apppj1+
PSDBGSRV
DBGQ
1
0
- cs9apppj1+
PSPUBDSP
PUBDQ_dflt
1
0
- cs9apppj1+
WSL
00001.00020
1
0
- cs9apppj1+
PSWATCHSRV
WATCH
1
0
- cs9apppj1+
PSBRKDSP
BRKDQ_dflt
1
0
- cs9apppj1+
JSL
00095.00200
1
0
- cs9apppj1+
JREPSVR
00094.00250
1
0
- cs9apppj1+
PSSUBDSP
SUBDQ_dflt
1
0
- cs9apppj1+
PSMONITORSRV   MONITOR
1
0
- cs9apppj1+
PSSAMSRV
SAMQ
2
0
- cs9apppj1+
Apologies if this should be posted elsewhere or is an annoyingly newb question. As you may have guessed. I'm a PeopleSoft guy and most of this Tuxedo stuff is usually obfuscated.
Best Regards,
Dave.
David Fist
PeopleSoft Administrator
University of Newcastle

Many thanks to everyone for the help to date.
I seem to be running into Re: Help! .TMIB service not returning local attributes, with the TA_NQUEUE value is not being returned for T_QUEUE or T_SVCGRP because the T_DOMAIN:TA_LDBAL value is set to N which problematic as "# Queued" is the value I'm most interested in. Basically I'm just trying to get the same information that tmadmin's "pq" command generates using .TMIB and FML.
Is this possible?
> pq
Prog Name      Queue Name # Serve Wk Queued # Queued Ave. Len    Machine
PSBRKHND       BRKHQ_dflt        1         -         0         - cs9apppj1+
PSSUBHND       SUBHQ_dflt        1         -         0         - cs9apppj1+
JSL            00095.00200       1         -         0         - cs9apppj1+
JREPSVR        00094.00250       1         -         0         - cs9apppj1+
PSBRKDSP       BRKDQ_dflt        1         -         0         - cs9apppj1+
PSPPMSRV       PPMQ2             1         -         0         - cs9apppj1+
PSPUBHND       PUBHQ_dflt        1         -         0         - cs9apppj1+
PSWATCHSRV     WATCH             1         -         0         - cs9apppj1+
PSSUBDSP       SUBDQ_dflt        1         -         0         - cs9apppj1+
PSMONITORSRV   MONITOR           1         -         0         - cs9apppj1+
PSSAMSRV       SAMQ              2         -         0         - cs9apppj1+
WSL            00001.00020       1         -         0         - cs9apppj1+
PSAPPSRV       APPQ              2         -         0         - cs9apppj1+
PSPUBDSP       PUBDQ_dflt        1         -         0         - cs9apppj1+
PSDBGSRV       DBGQ              1         -         0         - cs9apppj1+
BBL            153494            1         -         0         - cs9apppj1+
Note, I am getting a value back for TA_WKQUEUED... how does this differ from TA_NQUEUED?
Cheers,
Dave

Code for using thin client over connection pool to access blob and clob

Hi,
Currently I am running WL5.1SP12 with oracle thin client 8.1.7 to access blob
and clob data. As the performance for concurrent users is very bad, I like to
use the thin client over a connection pool to access the blob and clob instead.
My question is whether this is possible and if so does anyone have a sample code?
Thanks.
This is urgent as the site has to roll out in 2 weeks..
Rgd,
Jason

See http://e-docs.bea.com/wls/docs61/jdbc/thirdparty.html#1043705.
"Jason" <[email protected]> wrote in message news:3eba851f$[email protected]..
>
Hi Stephen,
Thanks for the reply. Can I confirm that what you are saying is that in release
6.1 I am able to access blob/clob data via thin client over connection pool?
Rgd.
Jason
"Stephen Felts" <[email protected]> wrote:
Blob/clob support through the connection pool came in with release 6.1.
"Jason" <[email protected]> wrote in message news:[email protected]..
Hi,
Currently I am running WL5.1SP12 with oracle thin client 8.1.7 to accessblob
and clob data. As the performance for concurrent users is very bad,I like to
use the thin client over a connection pool to access the blob and clobinstead.
My question is whether this is possible and if so does anyone havea sample code?
Thanks.
This is urgent as the site has to roll out in 2 weeks..
Rgd,
Jason

Error in creating a connection pool (No suitable driver)

I try to create a connection pool in a Weblogic server 7.0 with the following config:
URL:
jdbc:oracle:oci9:@db_name
Driver Classname:
oracle.jdbc.driver.OracleDriver
Properties(key=value):
user=user_name
password=user_password
dll=ocijdbc9
server=db_name
protocol=oci
my computer (windows 2000) has installed Oracle 9i client, and this connection
pool will connect to Oracle 8i server. Besides, I have config classes12.zip in
the "classpath" and ocijdbc9.dll in the "path" environment variables.
Can Oracle 9i driver connect to a Oracle 8i server? Or there is other problems?
Thanks in advance.

Please try URL = jdbc:oracle:oci8:@db_name... that should be fine.
Yes, you can connect to 8i oracle database using 9i driver.
Also, make sure you have classes12.zip in classpath and ocijdbc9.dll in path.
Thanks,
Mitesh
Jacky Ho wrote:
I try to create a connection pool in a Weblogic server 7.0 with the following config:
URL:
jdbc:oracle:oci9:@db_name
Driver Classname:
oracle.jdbc.driver.OracleDriver
Properties(key=value):
user=user_name
password=user_password
dll=ocijdbc9
server=db_name
protocol=oci
my computer (windows 2000) has installed Oracle 9i client, and this connection
pool will connect to Oracle 8i server. Besides, I have config classes12.zip in
the "classpath" and ocijdbc9.dll in the "path" environment variables.
Can Oracle 9i driver connect to a Oracle 8i server? Or there is other problems?
Thanks in advance.

KIMYONG : Applications Database Connection Pool 관련 parameter 설명

Purpose
JVM 이 과도한 CPU / Memory를 사용하게 되어 Application Performance에 영향을 미칠때가 있으며 이럴경우 Connection Pool 관련하여 Parameter Tunning을 해야 할때가 있습니다. 이때 사용되는 Parameter들의 의미를 설명하고자 합니다.
The Applications Database Connection Pool is a pool of JDBC database connections that are shared among java applications. Applications obtain connections from the pool by using the getJDBCConnection(...) methods of AppsContext.
Essentially, each AppsContext has a single database connection associated with it at all times.
The AOL/J layer internally borrows and returns this connection to the pool as needed to maintain connection reference that is properly initialized for the current Java tier AOL security context and NLS state.
FND_MAX_JDBC_CONNECTIONS
============================
The maximum pool size is the maximum allowed sum of the number of available connections and thenumber of locked connections. If the pool reaches the maximum size and all connections are locked, new clients will not be able to borrow a connection until one of the current clients has returned one. The default setting for this parameter is essentially unlimited (about 2 billion).
FND_JDBC_BUFFER_MIN
======================
The buffer minimum is the minimum number of connections that the pool should try to maintain in the available list. When the buffer size falls below the buffer minimum, the pool maintenance thread will be notified to create new connections. When notified, the thread will immediately attempt to create the number of connections to fill the difference. New connections will not be created if the pool is already at its maximum size. When creating new connections the thread uses the attributes of the most recent client request that resulted in a new connection being created.
Setting this parameter to "0" will disable maintenance of the buffer minimum.
However, the buffer maximum will still be maintained.
Setting this parameter to a number greater than the maximum pool size(FND_MAX_JDBC_CONNECTIONS) will disable all buffer maintenance.
FND_JDBC_BUFFER_MAX
======================
The buffer maximum is the maximum number of connections that the pool should try to maintain in the available list. During heavy usage, the buffer may exceed this maximum. However, during periods of low usage, the maintenance thread will decrease the buffer size until the buffer maximum is reached.
If the value of this parameter is an integer, (for example "20") the buffer maximum is static. If the value is a percent (for example, "20%"), the buffer maximum is not constant but instead is calculated dynamically as a percent of total pool size. The buffer minimum is also taken into account when
determining a dynamic buffer maximum.
The exact expression used is:
maximum(t) = buffer minimum + ( (FND_JDBC_BUFFER_MAX/100) * size(t) )
where maximum(t) and size(t) are the buffer maximum and pool size at some time t.
The thread is configured to periodically check the buffer size. If the buffer size is greater than the maximum, the thread will remove either the number of available connections specified by FND_JDBC_BUFFER_DECAY_SIZE or the number of connections in excess of the buffer minimum, whichever is smaller. When connections are removed from the available list, the least recently used ones are removed first.
Setting this parameter to100%, or to a number equal to FND_MAXIMUM_JDBC_CONNECTIONS, or to a number less than or equal to FND_JDBC_BUFFER_MIN will effectively prevent the maintenance thread from ever removing any connections.
FND_JDBC_BUFFER_DECAY_INTERVAL
===================================
The buffer decay interval specifies how often the connection pool maintenance thread should check the buffer size. The thread will check the buffer size at most once every FND_JDBC_BUFFER_DECAY_INTERVAL seconds. The actual time between consecutive thread cycles will vary somewhat depending on the JVM load.
This parameter, along with FND_JDBC_BUFFER_DECAY_SIZE, allows the buffer decay rate to be tuned. For example, if the buffer decay size is 2 and the buffer decay interval is one minute, the buffer decay rate will never exceed two connections per minute. When connections are removed, the least recently used ones are removed first.
FND_JDBC_BUFFER_DECAY_SIZE
=============================
The buffer decay size specifies the maximum number of connections that should be removed during any single thread cycle during which the number of available connections is greater than the buffer size. This parameter, along with FND_JDBC_BUFFER_DECAY_INTERVAL, allows the buffer decay rate to be tuned.
FND_JDBC_MAX_WAIT_TIME
=========================
The maximum wait time specifies how much time a client should spend trying to get a connection. The borrow algorithm, used to borrow an object from the pool, contains check points at which the elapsed time is compared to the maximum wait time. If it exceeds the maximum wait time, then a null object will be returned to the client. The pre-configured value for the maximum wait time is
10 seconds.
FND_JDBC_SELECTION_POLICY
============================
The selection policy determines how a connection is selected from the list of available connections for a particular client. The connection pool is pre-configured to use a cost-based selection algorithm, which selects the connection that will require the smallest amount of initialization to match the
client's context.
FND_JDBC_USABLE_CHECK
===========================
The FND_JDBC_USABLE_CHECK parameter governs whether a pl/sql query is performed before giving a connection to a client. The pool checks whether a connection is usable before handing it to a client. This always involves checking that the connection is not null and is not closed. If FND_JDBC_USABLE_CHECK is set to true, then it also verifies that the connection can be used to perform a simple PL/SQL query. (This parameter may have to be set to "true" in order to clean up
connections to a database that has been restarted.)
FND_JDBC_CONTEXT_CHECK
==========================
The FND_JDBC_CONTEXT_CHECK parameter governs whether the AOL security context and NLS state is obtained from the database when the connection is returned to the pool. If FND_JDBC_CONTEXT_CHECK is "true", when the connection is returned to the pool, the AOL security context and NLS state will be obtained from the database. (This is implemented in the DBConnObj.isReusable() method). This check must be done when the connection is returned (rather than when it is borrowed) so that the selection matching algorithm has access to the actual
session context of the connections in the available list.
FND_JDBC_PLSQL_RESET
========================
The PL/SQL reset flag, set using the variable FND_JDBC_PLSQL_RESET, governs whether the PL/SQL state associated with a connection should be freed before the pool hands the connection to the client. By default this flag is false.
If the flag is set by true, by including the line "FND_JDBC_PLSQL_RESET=true" in the .dbc file, each connection to the database will have its PL/SQL state cleared before the pool returns the connection to the client.
This is how it works. After the pool selects a connection from the available list for a client, it initializes the connection. One of the things initialization does is to set a flag that is later used by SessionManager to determine if the apps initialization routine needs to be performed for the connection. When FND_JDBC_PLSQL_RESET has been set to "true", this flag will always be set to true. After the pool initializes the connection, it also checks whether the connection is usable. In this case, this check will include a call to DBMS_SESSION.RESET_PACKAGE, which frees the PL/SQL state. The table below summaries the affect of FND_JDBC_PLSQL_RESET and the other safety check parameters on borrowing a connection from the pool.
The FND_JDBC_PLSQL_RESET parameter has been added to only to address the case where production PL/SQL global bugs are known to exist. The performance of the pool is reduced by setting this flag to true.
Reference : Note 264599.1

Purpose
JVM 이 과도한 CPU / Memory를 사용하게 되어 Application Performance에 영향을 미칠때가 있으며 이럴경우 Connection Pool 관련하여 Parameter Tunning을 해야 할때가 있습니다. 이때 사용되는 Parameter들의 의미를 설명하고자 합니다.
The Applications Database Connection Pool is a pool of JDBC database connections that are shared among java applications. Applications obtain connections from the pool by using the getJDBCConnection(...) methods of AppsContext.
Essentially, each AppsContext has a single database connection associated with it at all times.
The AOL/J layer internally borrows and returns this connection to the pool as needed to maintain connection reference that is properly initialized for the current Java tier AOL security context and NLS state.
FND_MAX_JDBC_CONNECTIONS
============================
The maximum pool size is the maximum allowed sum of the number of available connections and thenumber of locked connections. If the pool reaches the maximum size and all connections are locked, new clients will not be able to borrow a connection until one of the current clients has returned one. The default setting for this parameter is essentially unlimited (about 2 billion).
FND_JDBC_BUFFER_MIN
======================
The buffer minimum is the minimum number of connections that the pool should try to maintain in the available list. When the buffer size falls below the buffer minimum, the pool maintenance thread will be notified to create new connections. When notified, the thread will immediately attempt to create the number of connections to fill the difference. New connections will not be created if the pool is already at its maximum size. When creating new connections the thread uses the attributes of the most recent client request that resulted in a new connection being created.
Setting this parameter to "0" will disable maintenance of the buffer minimum.
However, the buffer maximum will still be maintained.
Setting this parameter to a number greater than the maximum pool size(FND_MAX_JDBC_CONNECTIONS) will disable all buffer maintenance.
FND_JDBC_BUFFER_MAX
======================
The buffer maximum is the maximum number of connections that the pool should try to maintain in the available list. During heavy usage, the buffer may exceed this maximum. However, during periods of low usage, the maintenance thread will decrease the buffer size until the buffer maximum is reached.
If the value of this parameter is an integer, (for example "20") the buffer maximum is static. If the value is a percent (for example, "20%"), the buffer maximum is not constant but instead is calculated dynamically as a percent of total pool size. The buffer minimum is also taken into account when
determining a dynamic buffer maximum.
The exact expression used is:
maximum(t) = buffer minimum + ( (FND_JDBC_BUFFER_MAX/100) * size(t) )
where maximum(t) and size(t) are the buffer maximum and pool size at some time t.
The thread is configured to periodically check the buffer size. If the buffer size is greater than the maximum, the thread will remove either the number of available connections specified by FND_JDBC_BUFFER_DECAY_SIZE or the number of connections in excess of the buffer minimum, whichever is smaller. When connections are removed from the available list, the least recently used ones are removed first.
Setting this parameter to100%, or to a number equal to FND_MAXIMUM_JDBC_CONNECTIONS, or to a number less than or equal to FND_JDBC_BUFFER_MIN will effectively prevent the maintenance thread from ever removing any connections.
FND_JDBC_BUFFER_DECAY_INTERVAL
===================================
The buffer decay interval specifies how often the connection pool maintenance thread should check the buffer size. The thread will check the buffer size at most once every FND_JDBC_BUFFER_DECAY_INTERVAL seconds. The actual time between consecutive thread cycles will vary somewhat depending on the JVM load.
This parameter, along with FND_JDBC_BUFFER_DECAY_SIZE, allows the buffer decay rate to be tuned. For example, if the buffer decay size is 2 and the buffer decay interval is one minute, the buffer decay rate will never exceed two connections per minute. When connections are removed, the least recently used ones are removed first.
FND_JDBC_BUFFER_DECAY_SIZE
=============================
The buffer decay size specifies the maximum number of connections that should be removed during any single thread cycle during which the number of available connections is greater than the buffer size. This parameter, along with FND_JDBC_BUFFER_DECAY_INTERVAL, allows the buffer decay rate to be tuned.
FND_JDBC_MAX_WAIT_TIME
=========================
The maximum wait time specifies how much time a client should spend trying to get a connection. The borrow algorithm, used to borrow an object from the pool, contains check points at which the elapsed time is compared to the maximum wait time. If it exceeds the maximum wait time, then a null object will be returned to the client. The pre-configured value for the maximum wait time is
10 seconds.
FND_JDBC_SELECTION_POLICY
============================
The selection policy determines how a connection is selected from the list of available connections for a particular client. The connection pool is pre-configured to use a cost-based selection algorithm, which selects the connection that will require the smallest amount of initialization to match the
client's context.
FND_JDBC_USABLE_CHECK
===========================
The FND_JDBC_USABLE_CHECK parameter governs whether a pl/sql query is performed before giving a connection to a client. The pool checks whether a connection is usable before handing it to a client. This always involves checking that the connection is not null and is not closed. If FND_JDBC_USABLE_CHECK is set to true, then it also verifies that the connection can be used to perform a simple PL/SQL query. (This parameter may have to be set to "true" in order to clean up
connections to a database that has been restarted.)
FND_JDBC_CONTEXT_CHECK
==========================
The FND_JDBC_CONTEXT_CHECK parameter governs whether the AOL security context and NLS state is obtained from the database when the connection is returned to the pool. If FND_JDBC_CONTEXT_CHECK is "true", when the connection is returned to the pool, the AOL security context and NLS state will be obtained from the database. (This is implemented in the DBConnObj.isReusable() method). This check must be done when the connection is returned (rather than when it is borrowed) so that the selection matching algorithm has access to the actual
session context of the connections in the available list.
FND_JDBC_PLSQL_RESET
========================
The PL/SQL reset flag, set using the variable FND_JDBC_PLSQL_RESET, governs whether the PL/SQL state associated with a connection should be freed before the pool hands the connection to the client. By default this flag is false.
If the flag is set by true, by including the line "FND_JDBC_PLSQL_RESET=true" in the .dbc file, each connection to the database will have its PL/SQL state cleared before the pool returns the connection to the client.
This is how it works. After the pool selects a connection from the available list for a client, it initializes the connection. One of the things initialization does is to set a flag that is later used by SessionManager to determine if the apps initialization routine needs to be performed for the connection. When FND_JDBC_PLSQL_RESET has been set to "true", this flag will always be set to true. After the pool initializes the connection, it also checks whether the connection is usable. In this case, this check will include a call to DBMS_SESSION.RESET_PACKAGE, which frees the PL/SQL state. The table below summaries the affect of FND_JDBC_PLSQL_RESET and the other safety check parameters on borrowing a connection from the pool.
The FND_JDBC_PLSQL_RESET parameter has been added to only to address the case where production PL/SQL global bugs are known to exist. The performance of the pool is reduced by setting this flag to true.
Reference : Note 264599.1

What is Connection Pooling

Hi Friends
What is "Connection Pooling"
I am developing Java Application using ms sql server 2000 database
Pl explain me about this
thanxinadvance
yours
Rajesh

In a basic DataSource implementation, there is a 1:1 correspondence between the
client�s Connection object and the physical database connection. When the
Connection object is closed, the physical connection is dropped. Thus, the
overhead of opening, initializing, and closing the physical connection is incurred for
each client session.
A connection pool solves this problem by maintaining a cache of physical database
connections that can be reused across client sessions. Connection pooling greatly
improves performance and scalability, particularly in a three-tier environment where
multiple clients can share a smaller number of physical database connections.
Nitin

Install PT8.53 with Linux Issue: Jolt client (ip address 192.168.196.102) does not have proper application password

Folks,
Hello.
I am installing PeopleTools 8.53 with Oracle Database Server 11gR1 and OS Oracle Linux 5.10.
Data Mover Bootstrap and Application Designer can log into Database instance successfully. My procedure to run PIA is below:
Step 1: start Oracle Database Server and LISTENR is listening.
Step 2: start Application Server ./psadmin and 8 processes are started.
Step 3: start WebLogic Server PIA /opt/PT8.53/webserv/PT853/bin/startPIA.sh
In Browser, http://192.168.196.102:8000/ps/signon.html comes up successfully. But when sign in using UserID PSADMIN and password "myname", I get the error message in Browser as below:
The application server is down at this time.
CHECK APPSERVER LOGS. THE SITE BOOTED WITH INTERNAL DEFAULT SETTINGS, BECAUSE OF: bea.jolt.ServiceException: Invalid Session
We've detected that your operating system is not supported by this website. For best results, use one of the following operating systems:
Mac OS X 10.6(Snow Leopard)
Mac OS X 10.5(Leopard)
iPad
Oracle Linux Enterprise
Mac OS X 10.4(Tiger)
Windows 8
Windows 7
Mac OS X 10.7(Lion)
Regarding Application Designer, both Database Type "Oracle" and Connection Type "Application Server", UserID "PSADMIN" and password "myname" login successfully. I view TUXLOG (current Tuxedo log file) and its last screen is below:
191723.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191723.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191723.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191724.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191724.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191724.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191724.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191724.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191725.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191725.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191725.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191726.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191726.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191726.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191726.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191726.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191727.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191727.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191727.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
191727.lucylinux.lucydomain!JSH.32462.2485226496.-2: JOLT_CAT:1626: "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password"
I View APPSRV_1023.LOG (current server log file) and its content is below:
PSADMIN.32259 (0) [2013-10-23T18:55:12.134](0) Begin boot attempt on domain PT853
PSAPPSRV.32290 (0) [2013-10-23T18:55:35.701](0) PeopleTools Release 8.53 (Linux) starting. Tuxedo server is APPSRV(99)/1
PSAPPSRV.32290 (0) [2013-10-23T18:55:35.923](0) Cache Directory being used: /home/user/psft/pt/8.53/appserv/PT853/CACHE/PSAPPSRV_1/
PSAPPSRV.32290 (0) [2013-10-23T18:56:19.256](2) App server host time skew is DB+00:00:00 (ORACLE PT853)
PSAPPSRV.32290 (0) [2013-10-23T18:56:23.504](0) Server started
PSAPPSRV.32290 (0) [2013-10-23T18:56:23.507](3) Detected time zone is EDT
PSAPPSRV.32338 (0) [2013-10-23T18:56:25.793](0) PeopleTools Release 8.53 (Linux) starting. Tuxedo server is APPSRV(99)/2
PSAPPSRV.32338 (0) [2013-10-23T18:56:26.003](0) Cache Directory being used: /home/user/psft/pt/8.53/appserv/PT853/CACHE/PSAPPSRV_2/
PSAPPSRV.32338 (0) [2013-10-23T18:57:08.871](2) App server host time skew is DB+00:00:00 (ORACLE PT853)
PSAPPSRV.32338 (0) [2013-10-23T18:57:10.662](0) Server started
PSAPPSRV.32338 (0) [2013-10-23T18:57:10.663](3) Detected time zone is EDT
PSSAMSRV.32388 (0) [2013-10-23T18:57:12.159](2) Min instance is set to 1. To avoid loss of service, configure Min instance to atleast 2.
PSSAMSRV.32388 (0) [2013-10-23T18:57:12.168](0) PeopleTools Release 8.53 (Li nux) starting. Tuxedo server is APPSRV(99)/100
PSSAMSRV.32388 (0) [2013-10-23T18:57:12.265](0) Cache Directory being used: /home/user/psft/pt/8.53/appserv/PT853/CACHE/PSSAMSRV_100/
PSSAMSRV.32388 (0) [2013-10-23T18:57:59.414](0) Server started
PSSAMSRV.32388 (0) [2013-10-23T18:57:59.416](3) Detected time zone is EDT
PSADMIN.32259 (0) [2013-10-23T18:58:48.149](0) End boot attempt on domain PT853
PSAPPSRV.32290 (1) [2013-10-23T18:59:06.144 GetCertificate](3) Returning context. ID=PSADMIN, Lang=ENG, UStreamId=185906140_32290.1, Token=PT_LOCAL/2013-10-23-11.59.26.248432/PSADMIN/ENG/vSz0ix+wq8d+zPRwQ0Wa4hcek0Q=
~
I think the error is indicated in TUXLOG file "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password". The application password "myname" in Browser http://192.168.196.102:8000/ps/signon.html page is not working. I use the same password "myname" to login Data Mover Bootstrap mode, Application Designer, and Application Server psadmin configuration successfully. I have tried a few other passwords in Browser http://192.168.196.102:8000/ps/signon.html page but not working.
My question is:
How to solve Sign In issue on http://192.168.196.102:8000/ps/signon.html that is "ERROR: Jolt client (ip address 192.168.196.102) does not have proper application password" ?
Thanks.

Dear Nicolas,
Hello. I have used the same password for "DomainConnectPswd" in the file Configuration.properties with that for Application Server setting. Eventually, UserID PSADMIN sign in http://192.168.196.102:8000/ps/signon.html successfully. PeopleTools 8.53 runs correctly in Browser.
It seems that whether upgrade Oracle Linux 5.0 to the latest 5.10 does not have effect !
I am very grateful to your great help for this installation of PT8.53 with Linux and Oracle Database !

How to run a sample Jolt client

Can any one explain me how to run a sample jolt client.
Iam trying to run the following jolt client code ToUpper.java at the command prompt but I am getting the following error.I am getting the same error when i run the Jrepository Applet RE.html.
D:\ToUpper>javac ToUpper.java
D:\ToUpper>java ToUpper
bea.jolt.SessionException: Cannot connect to any //localhost:3050.
Reason:NwHdlr: Network Error: chkauth: J_CHECKAUTH FAILED
at bea.jolt.JoltSessionAttributes.getDomainInfoJoltSessionAttributes.java:584)
at bea.jolt.JoltSessionAttributes.checkAuthenticationLevel(JoltSessionAttributes.java:507)
at ToUpper.main(ToUpper.java:20).
I have the tlistener running and provided apppassword and userpassword as my System login password where I have the complete Tuxedo Installation(server and client). Please see the attached sample jolt client program I am trying to run. I am not sure what configuration Settings I need to do.
ToUpper.java
/* Copyright 1996 BEA Systems, Inc. All Rights Reserved */
import bea.jolt.*;
public class ToUpper
public static void main (String[] args)
JoltSession session;
JoltSessionAttributes sattr;
JoltRemoteService toupper;
JoltTransaction trans;
String userName=null;
String userPassword=null;
String appPassword=null;
String userRole="myapp";
String outstr;
          try{
sattr = new JoltSessionAttributes();
sattr.setString(sattr.APPADDRESS, "//GVC3ZA03TESTING:3050");
switch (sattr.checkAuthenticationLevel())
case JoltSessionAttributes.NOAUTH:
break;
case JoltSessionAttributes.APPASSWORD:
appPassword = "123456"//"appPassword";
break;
case JoltSessionAttributes.USRPASSWORD:
userName = "myname";
userPassword = "123456";
appPassword = "123456";
break;
sattr.setInt(sattr.IDLETIMEOUT, 300);
session = new JoltSession(sattr, userName, userRole,
userPassword, appPassword);
toupper = new JoltRemoteService ("TOUPPER", session);
toupper.setString("STRING", "hello world");
toupper.call(null);
outstr = toupper.getStringDef("STRING", null);
if (outstr != null)
System.out.println(outstr);
session.endSession();
System.exit(0);
          }catch(Exception e){
          e.printStackTrace();
} // end main
} // end ToUpper

Hi Todd,
I am not getting the jcheckauthentication error now as i changed the port no. to the port where JSL is running.Now I am getting this error.Also find the ULOG contents pasted below.
D:\bea\tuxedo9.1\samples\jolt\ToUpper>java ToUpper
Authentication Level set To :0
Exception caught error no is:6
bea.jolt.ServiceException: TPENOENT - no entry found
at bea.jolt.JoltRemoteService.decodeCALL(JoltRemoteService.java:460)
at bea.jolt.JoltRemoteService.call(JoltRemoteService.java:345)
at bea.jolt.JoltRemoteService.call(JoltRemoteService.java:267)
at ToUpper.main(ToUpper.java:39)
I have checked the jrepository file and also the Applet window for the service defination(TOUPPER)but still its not recognizing the service.Is there some configuration thing I have missed out before running JOLT client.
ULOG File Contents
132947.GVC3ZA03TESTING!JSH.4000.2464.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name ''; client name 'myapp'"
132956.GVC3ZA03TESTING!WSL.432.5308.0: WSNAT_CAT:1196: INFO: Terminating handlers in preparation for shutdown
132956.GVC3ZA03TESTING!WSL.432.5308.0: WSNAT_CAT:1197: INFO: Exiting system
132956.GVC3ZA03TESTING!JSL.2644.2356.0: JOLT_CAT:1506: "INFO: Terminating Jolt administration services in preparation for shutdown"
132956.GVC3ZA03TESTING!JSL.2644.2356.0: JOLT_CAT:1196: "INFO: Terminating handlers in preparation for shutdown"
132956.GVC3ZA03TESTING!JSH.4000.2464.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name 'jolt'; client name 'joltadmin'"
132956.GVC3ZA03TESTING!JSL.2644.2356.0: JOLT_CAT:1197: "INFO: Exiting system"
132956.GVC3ZA03TESTING!DMADM.5844.5348.0: CMDGW_CAT:1655: INFO: DMADMSVR is exiting
132959.GVC3ZA03TESTING!BBL.3216.4372.0: CMDTUX_CAT:26: INFO: The BBL is exiting system
133021.GVC3ZA03TESTING!tmloadcf.6104.3164.-2: 02-01-2007: Tuxedo Version 9.1, 32-bit
133021.GVC3ZA03TESTING!tmloadcf.6104.3164.-2: CMDTUX_CAT:872: INFO: TUXCONFIG file D:\bea\tuxedo9.1\samples\jolt\ToUpper\tuxconfig has been updated
133028.GVC3ZA03TESTING!BBL.6140.5124.0: 02-01-2007: Tuxedo Version 9.1, 32-bit, Patch Level (none)
133028.GVC3ZA03TESTING!BBL.6140.5124.0: LIBTUX_CAT:262: INFO: Standard main starting
133028.GVC3ZA03TESTING!DMADM.4928.1868.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
133028.GVC3ZA03TESTING!DMADM.4928.1868.0: LIBTUX_CAT:262: INFO: Standard main starting
133028.GVC3ZA03TESTING!DMADM.4928.1868.0: CMDGW_CAT:3149: INFO: BDMCONFIG environment variable not set. Using $APPDIR/BDMCONFIG
133028.GVC3ZA03TESTING!DMADM.4928.1868.0: CMDGW_CAT:3761: INFO: Using version 2 BDMCONFIG, 3DES is enabled.
133028.GVC3ZA03TESTING!JSL.5608.6088.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
133028.GVC3ZA03TESTING!JSL.5608.6088.0: LIBTUX_CAT:262: INFO: Standard main starting
133028.GVC3ZA03TESTING!JSL.5608.6088.0: INFO: JOLT Listener version-BEA Jolt 9.1
133028.GVC3ZA03TESTING!JSL.5608.6088.0: JOLT_CAT:1563: "INFO: Serial Number : <454493271161-2140437240256>, Expiration Date : <2007-02-15>"
133028.GVC3ZA03TESTING!JSL.5608.6088.0: JOLT_CAT:1564: "INFO: Licensee : <BEA Evaluation Customer>"
133029.GVC3ZA03TESTING!JSH.6028.5748.-2: 02-01-2007: Tuxedo Version 9.1, 32-bit
133029.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1030: "INFO: Jolt Handler joining application"
133029.GVC3ZA03TESTING!JSH.6028.5748.-2: INFO: JOLT Handler version-BEA Jolt 9.1
133029.GVC3ZA03TESTING!JREPSVR.3476.4980.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
133029.GVC3ZA03TESTING!JREPSVR.3476.4980.0: LIBTUX_CAT:262: INFO: Standard main starting
133029.GVC3ZA03TESTING!JREPSVR.3476.4980.0: Current version: BEA Jolt 9.1
133029.GVC3ZA03TESTING!JREPSVR.3476.4980.0: Repository "D:\bea\tuxedo9.1\udataobj\jolt\repository\jrepository" (16 records) is writable.
133029.GVC3ZA03TESTING!WSL.3292.4892.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
133029.GVC3ZA03TESTING!WSL.3292.4892.0: LIBTUX_CAT:262: INFO: Standard main starting
133029.GVC3ZA03TESTING!WSH.2568.3772.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
133029.GVC3ZA03TESTING!WSH.2568.3772.0: WSNAT_CAT:1030: INFO: Work Station Handler joining application
133029.GVC3ZA03TESTING!WSH.5764.3836.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
133029.GVC3ZA03TESTING!WSH.5764.3836.0: WSNAT_CAT:1030: INFO: Work Station Handler joining application
133242.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
133300.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name ''; client name 'myapp'"
133300.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
133359.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name ''; client name 'myapp'"
133456.GVC3ZA03TESTING!JSH.6028.5748.-2: Fldid32(ACCOUNT_ID) failed for INQUIRY: LIBFML_CAT:8: ERROR: Unknown field name. Maybe FIELDTBLS32 is not set properly.
133612.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
143325.GVC3ZA03TESTING!JSH.6028.5748.-2: Fldid(SAMOUNT) failed for DEPOSIT: LIBFML_CAT:11: ERROR: Cannot find or open field table. Maybe FIELDTBLS is not set properly.
144116.GVC3ZA03TESTING!WSL.3292.4892.0: WSNAT_CAT:1196: INFO: Terminating handlers in preparation for shutdown
144116.GVC3ZA03TESTING!WSL.3292.4892.0: WSNAT_CAT:1197: INFO: Exiting system
144116.GVC3ZA03TESTING!JSL.5608.6088.0: JOLT_CAT:1506: "INFO: Terminating Jolt administration services in preparation for shutdown"
144116.GVC3ZA03TESTING!JSL.5608.6088.0: JOLT_CAT:1196: "INFO: Terminating handlers in preparation for shutdown"
144116.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name 'jolt'; client name 'joltadmin'"
144116.GVC3ZA03TESTING!JSL.5608.6088.0: JOLT_CAT:1197: "INFO: Exiting system"
144116.GVC3ZA03TESTING!DMADM.4928.1868.0: CMDGW_CAT:1655: INFO: DMADMSVR is exiting
144119.GVC3ZA03TESTING!BBL.6140.5124.0: CMDTUX_CAT:26: INFO: The BBL is exiting system
144142.GVC3ZA03TESTING!tmloadcf.2668.3316.-2: 02-01-2007: Tuxedo Version 9.1, 32-bit
144142.GVC3ZA03TESTING!tmloadcf.2668.3316.-2: CMDTUX_CAT:872: INFO: TUXCONFIG file D:\bea\tuxedo9.1\samples\jolt\ToUpper\tuxconfig has been updated
144148.GVC3ZA03TESTING!BBL.4144.4376.0: 02-01-2007: Tuxedo Version 9.1, 32-bit, Patch Level (none)
144148.GVC3ZA03TESTING!BBL.4144.4376.0: LIBTUX_CAT:262: INFO: Standard main starting
144148.GVC3ZA03TESTING!DMADM.4436.5968.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!DMADM.4436.5968.0: LIBTUX_CAT:262: INFO: Standard main starting
144148.GVC3ZA03TESTING!DMADM.4436.5968.0: CMDGW_CAT:3149: INFO: BDMCONFIG environment variable not set. Using $APPDIR/BDMCONFIG
144148.GVC3ZA03TESTING!DMADM.4436.5968.0: CMDGW_CAT:3761: INFO: Using version 2 BDMCONFIG, 3DES is enabled.
144148.GVC3ZA03TESTING!JSL.5072.2444.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!JSL.5072.2444.0: LIBTUX_CAT:262: INFO: Standard main starting
144148.GVC3ZA03TESTING!JSL.5072.2444.0: INFO: JOLT Listener version-BEA Jolt 9.1
144148.GVC3ZA03TESTING!JSL.5072.2444.0: JOLT_CAT:1563: "INFO: Serial Number : <454493271161-2140437240256>, Expiration Date : <2007-02-15>"
144148.GVC3ZA03TESTING!JSL.5072.2444.0: JOLT_CAT:1564: "INFO: Licensee : <BEA Evaluation Customer>"
144148.GVC3ZA03TESTING!JSH.5856.5268.-2: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!JSH.5856.5268.-2: JOLT_CAT:1030: "INFO: Jolt Handler joining application"
144148.GVC3ZA03TESTING!JSH.5856.5268.-2: INFO: JOLT Handler version-BEA Jolt 9.1
144148.GVC3ZA03TESTING!JREPSVR.2952.1248.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!JREPSVR.2952.1248.0: LIBTUX_CAT:262: INFO: Standard main starting
144148.GVC3ZA03TESTING!JREPSVR.2952.1248.0: Current version: BEA Jolt 9.1
144148.GVC3ZA03TESTING!JREPSVR.2952.1248.0: Repository "D:\bea\tuxedo9.1\udataobj\jolt\repository\jrepository" (16 records) is writable.
144148.GVC3ZA03TESTING!WSL.3040.5488.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!WSL.3040.5488.0: LIBTUX_CAT:262: INFO: Standard main starting
144148.GVC3ZA03TESTING!WSH.5740.2764.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!WSH.5740.2764.0: WSNAT_CAT:1030: INFO: Work Station Handler joining application
144148.GVC3ZA03TESTING!WSH.1784.5448.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!WSH.1784.5448.0: WSNAT_CAT:1030: INFO: Work Station Handler joining application
144157.GVC3ZA03TESTING!JSH.5856.5268.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
144207.GVC3ZA03TESTING!JSH.5856.5268.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name ''; client name 'myapp'"
144226.GVC3ZA03TESTING!JSH.5856.5268.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
144229.GVC3ZA03TESTING!JSH.5856.5268.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
144518.GVC3ZA03TESTING!WSL.3040.5488.0: WSNAT_CAT:1196: INFO: Terminating handlers in preparation for shutdown
144518.GVC3ZA03TESTING!WSL.3040.5488.0: WSNAT_CAT:1197: INFO: Exiting system
144518.GVC3ZA03TESTING!JSL.5072.2444.0: JOLT_CAT:1506: "INFO: Terminating Jolt administration services in preparation for shutdown"
144518.GVC3ZA03TESTING!JSL.5072.2444.0: JOLT_CAT:1196: "INFO: Terminating handlers in preparation for shutdown"
144518.GVC3ZA03TESTING!JSH.5856.5268.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name 'jolt'; client name 'joltadmin'"
144518.GVC3ZA03TESTING!JSL.5072.2444.0: JOLT_CAT:1197: "INFO: Exiting system"
144519.GVC3ZA03TESTING!DMADM.4436.5968.0: CMDGW_CAT:1655: INFO: DMADMSVR is exiting
144522.GVC3ZA03TESTING!BBL.4144.4376.0: CMDTUX_CAT:26: INFO: The BBL is exiting system
144537.GVC3ZA03TESTING!tmloadcf.4892.4980.-2: 02-01-2007: Tuxedo Version 9.1, 32-bit
144537.GVC3ZA03TESTING!tmloadcf.4892.4980.-2: CMDTUX_CAT:872: INFO: TUXCONFIG file D:\bea\tuxedo9.1\samples\jolt\ToUpper\tuxconfig has been updated
144543.GVC3ZA03TESTING!BBL.5440.4548.0: 02-01-2007: Tuxedo Version 9.1, 32-bit, Patch Level (none)
144543.GVC3ZA03TESTING!BBL.5440.4548.0: LIBTUX_CAT:262: INFO: Standard main starting
144543.GVC3ZA03TESTING!DMADM.1016.6128.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!DMADM.1016.6128.0: LIBTUX_CAT:262: INFO: Standard main starting
144543.GVC3ZA03TESTING!DMADM.1016.6128.0: CMDGW_CAT:3149: INFO: BDMCONFIG environment variable not set. Using $APPDIR/BDMCONFIG
144543.GVC3ZA03TESTING!DMADM.1016.6128.0: CMDGW_CAT:3761: INFO: Using version 2 BDMCONFIG, 3DES is enabled.
144543.GVC3ZA03TESTING!JSL.1796.5232.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!JSL.1796.5232.0: LIBTUX_CAT:262: INFO: Standard main starting
144543.GVC3ZA03TESTING!JSL.1796.5232.0: INFO: JOLT Listener version-BEA Jolt 9.1
144543.GVC3ZA03TESTING!JSL.1796.5232.0: JOLT_CAT:1563: "INFO: Serial Number : <454493271161-2140437240256>, Expiration Date : <2007-02-15>"
144543.GVC3ZA03TESTING!JSL.1796.5232.0: JOLT_CAT:1564: "INFO: Licensee : <BEA Evaluation Customer>"
144543.GVC3ZA03TESTING!JSH.3164.4076.-2: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!JSH.3164.4076.-2: JOLT_CAT:1030: "INFO: Jolt Handler joining application"
144543.GVC3ZA03TESTING!JSH.3164.4076.-2: INFO: JOLT Handler version-BEA Jolt 9.1
144543.GVC3ZA03TESTING!JREPSVR.860.2916.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!JREPSVR.860.2916.0: LIBTUX_CAT:262: INFO: Standard main starting
144543.GVC3ZA03TESTING!JREPSVR.860.2916.0: Current version: BEA Jolt 9.1
144543.GVC3ZA03TESTING!JREPSVR.860.2916.0: Repository "D:\bea\tuxedo9.1\udataobj\jolt\repository\jrepository" (16 records) is writable.
144543.GVC3ZA03TESTING!WSL.2596.4404.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!WSL.2596.4404.0: LIBTUX_CAT:262: INFO: Standard main starting
144543.GVC3ZA03TESTING!WSH.3508.5136.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!WSH.3508.5136.0: WSNAT_CAT:1030: INFO: Work Station Handler joining application
144543.GVC3ZA03TESTING!WSH.4288.5676.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!WSH.4288.5676.0: WSNAT_CAT:1030: INFO: Work Station Handler joining application
144548.GVC3ZA03TESTING!JSH.3164.4076.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
144634.GVC3ZA03TESTING!JSH.3164.4076.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name ''; client name 'myapp'"
144734.GVC3ZA03TESTING!JSH.3164.4076.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"

Tuxedo Service can not find a Jolt Client AFter timeout occured

We are using Java Servlet/Jolt client to access out backend
Tuxedo services.
Whenever a Tuxedo service timedout, like
"***tpcall failed |TPETIME - timeout occured|",
The Jolt client and Tuxedo services will be out of sync,
and Tuxedo Server will show following error message:
"JOLT_CAT:1518: "ERROR: Call handle and clientid have no matching requests".
Whenever this happends, we must reboot out Jolt client connection. Otherwise we
will keep geting above problem.
Our Jolt timeout time is 2 minutes. And Tuxedo block time is
1 min 30 sec. (We setip in our UBB config as
BLOCKTIME 9 #9*10s (def SCANUNIT)=90s or 1 min and 30s.).
It seems like Tuxedo service will be timeouted before Jolt timedout.
Could someone give us some suggestion about the above problem?
Thanks in advance!

Which version of Jolt are you using? This problem seems to have been fixed in
latest rolling patch for Jolt1.2. Contact BEA support for it.
-Deepak
Yux71 wrote:
We are using Java Servlet/Jolt client to access out backend
Tuxedo services.
Whenever a Tuxedo service timedout, like
"***tpcall failed |TPETIME - timeout occured|",
The Jolt client and Tuxedo services will be out of sync,
and Tuxedo Server will show following error message:
"JOLT_CAT:1518: "ERROR: Call handle and clientid have no matching requests".
Whenever this happends, we must reboot out Jolt client connection. Otherwise we
will keep geting above problem.
Our Jolt timeout time is 2 minutes. And Tuxedo block time is
1 min 30 sec. (We setip in our UBB config as
BLOCKTIME 9 #9*10s (def SCANUNIT)=90s or 1 min and 30s.).
It seems like Tuxedo service will be timeouted before Jolt timedout.
Could someone give us some suggestion about the above problem?
Thanks in advance!

How to configure Connection pooling in 10g AS for OCI client

Oracle Version: 10.1.3.1
Operating System: HP UX B.11.23 64 bit OS
Hello everyone,
In my connection pools setting of 10g Application server Control my application currently uses JDBC thin client. I need to move to OCI driver. My application uses JDBC 3.0
Can someone please help me out with the steps?
Thanks & Regards,
Prashant

http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-datasource-examples-howto.html

Server-side connection pooling for clients in different VM's

We have a need to centeralize our connection pool manger.
Is there a server-side connection pooling manger product to allow multiple clients running in different VM's to connect to and share connection objects to the same Database?
e.g. An applet, and a swing and a servlet/web app application all running in different VM's will connect to this central connection pool manager and share connection objects to the same DB.
We are using connection pooling for all of our applications but each application is maintaining its own connection pool and it is becomming a nightmare to manage and configure each one.
Also, we have to have at a miniumum one connection open per application to access the database regardless of wether we are using connection pool or not. This means that 100 apps(running in different VM's) will use at minimum 100 connections... where all of these 100 apps will do just fine with just 10-15 connections.
while back we used T3 server but can't find this product on BEA web site any more.
does jdbc 2.2 or 3.0 have any server side pool management specs outlined?
Please HELP as we can't afford anymore licensing fees for our company.
oh.. We can't open and close connections on each query as they will be slow.
any suggestions greatly appreciated.

if i understand you question, i don't think this is possible, since the Connection interface (and basically all of the related jdbc interfaces) aren't Serializable.. so they can't be sent over the wire to your client(s).
However, you could feasibly write some server side connection pool, and some server side facade which will allow clients to submit queries (either SQL String's or however you want to do it - obviously a more elegant solution involves a series of classes which dynamically create sql based on query criteria), then the server can grab a connection, execute the query, cycle through the results and populate some result object of your creation and send that back over the wire to your client(s).
.

Cannot startup connection pool no suitable driver /WLS 6.1 SP4

hi all,
i got a problem in creating a ConnectionPool with weblogic 6.1 sp4.
my connection pool has following config data:
URL:jdbc:oracle:[email protected]:1521:ESECD7
Driver:oracle.jdbc.driver.OracleDriver
props
username=aaaa
password=bbbb
in my startWebLogic.cmd i have following classpath:
set PATH=.\bin;%PATH%;c:\bea\wlserver6.1\config\mydomain;c:\bea\wlserver6.1\bin\oci817_8;c:\oracle\ora92\bin;%PATH%
set CLASSPATH=C:\oracle\ora92\jdbc\lib\classes111.zip;C:\oracle\ora92\jdbc\lib\classes12.zip;.;.\lib\weblogic_sp.jar;.\lib\weblogic.jar;c:\bea\jolt.jar;c:\bea\joltwls.jar;c:\bea\joltjse.jar
but i keep on gettign the exception Cannot startup connection pool.. no suitable
driver
to me it looks like everything is in classpath...
any ideas?
regards
marco

Marco wrote:
hi all,
i got a problem in creating a ConnectionPool with weblogic 6.1 sp4.
my connection pool has following config data:
URL:jdbc:oracle:[email protected]:1521:ESECD7
Driver:oracle.jdbc.driver.OracleDriver
props
username=aaaa
password=bbbb
in my startWebLogic.cmd i have following classpath:
set PATH=.\bin;%PATH%;c:\bea\wlserver6.1\config\mydomain;c:\bea\wlserver6.1\bin\oci817_8;c:\oracle\ora92\bin;%PATH%
set CLASSPATH=C:\oracle\ora92\jdbc\lib\classes111.zip;C:\oracle\ora92\jdbc\lib\classes12.zip;.;.\lib\weblogic_sp.jar;.\lib\weblogic.jar;c:\bea\jolt.jar;c:\bea\joltwls.jar;c:\bea\joltjse.jar
but i keep on gettign the exception Cannot startup connection pool.. no suitable
driver
to me it looks like everything is in classpath...
any ideas?
regards
marcoHi. Read the weblogi startServer script, and the startWLS script it calls. These
scripts build up a string which is added to the java commandline that starts
the server, with an argument -classpath ....... Unless the driver shows up there,
the server doesn't see it.
However, we already include a version of the oracle thin driver. It may not be
the best (it's old), so you will want to make sure you version gets in to the classpath
argument ahead of our stuff, but the old driver would have been invoked...
Therefore, I suspect your URL is not exactly correct. Please verify that this exact URL
works in a simple standalone JDBC program using the driver you want, without any
weblogic code in the picture.
thanks,
Joe

Execute threads used by connection pools

Hellos,
I am interested in fining out the relationship betwen the sizes of the execute
thread pool and a connection pool (jolt in my case).
I would like to know if each jolt conection uses up a thead from the default execute
queu or if the threads are taken from a different and reserved thread pool.
I am trying to tune up the thread pool size according to my pool sizes and so
on.
Any ideas?
Best regards,
Cristina

Cristina Ceballos wrote:
Hellos,
I am interested in fining out the relationship betwen the sizes of the execute
thread pool and a connection pool (jolt in my case).
I would like to know if each jolt conection uses up a thead from the default execute
queu or if the threads are taken from a different and reserved thread pool.
I am trying to tune up the thread pool size according to my pool sizes and so
on.
Any ideas?Hi. Connection pools do not use threads. Your application thread will get a connection
from the pool and use it. The relationship between threads and pools is that you want
to have enough connections in your pool to be able to serve all the threads that
may individually want a connection. Therefore for a server with 25 execute-threads,
you would typically define the pool to have 25 connections.
Joe
>
Best regards,
Cristina

RFC_ERROR_SYSTEM_FAILURE: Time limit exceeded. Connection Pool - JCO api

Hi Everyone
My Connection Pool parameters JCO api.
client=300
user=SISGERAL_RFC
passwd=******
ashost=14.29.3.120
sysnr=00
size=10
I have these parameters on my Connection Pool and sometimes appear these wrongs in my application:
1.
2006-01-07 13:20:37,414 ERROR com.tel.webapp.framework.SAPDataSource - ##### Time limit exceeded. LOCALIZED MESSAGE = Time limit exceeded. KEY = RFC_ERROR_SYSTEM_FAILURE GROUP = 104 TOSTRING = com.sap.mw.jco.JCO$Exception: (104) RFC_ERROR_SYSTEM_FAILURE: Time limit exceeded.
2.
2006-01-07 14:01:31,007 ERROR com.tel.webapp.framework.SapPoolConnectionManager - Timeout
Id like to know if is happening.
Are there something wrong with my connection pool?
What can be happening?
Thanks

Raghu,
Thanks for your response.
Yes, the pool connections are in place according to the sAP note mentioned above.
Regards,
Faisal

HELP - DB2 v9 & App Server PE 9.0 - PING Connection Pool Failure - HELP

I've been playing around with Studio Creator and DB2 v9 without any issues.
So I figured I would installed App Server PE 9 and use this as my production server that I would deploy to from studio creator.
However, in my efforts to set up db2/v9 I have been trying to ping a connection pool without any luck. I get the following message:
Operation 'pingConnectionPool' failed in 'resources' Config Mbean. Target exception message: Connection could not be allocated because: [sunm][DB2 JDBC Driver]Resource Limits Reached( ALLOCATE MEMORY FOR NEW SQLSTT FAILED ). Diagnostic Info: FUNCTION ID = 0049 , PROBE POINT = 0400 , TRACE POINT = 0030 , SUBCODE1 = 8B0F0000, SUBCODE2 = 78A68A98, SUBCODE3 = 00000000, ERROR MSG = Parser: Memory allocation error.
My datasource class name is com.sun.sql.jdbcx.db2.DB2DataSource.
And my resource type is javax.sql.datasource
I have copied smbase.jar, smdb2.jar and smutil.jar into c:\sun\appserver\lib
and I have all of the properties (serverName, portNumber, databaseName, user, password) created and set accordingly.
Any help would be greatly appreciated.

Here is how I got the DB2 Express-C and Sun PE 9.0 to work. ( at least base connectivity wise )
1. ) You have to have at least the DB2 Client installed on the system that will be communicating to the DB2 instance.
2.) The following jars will be needed ( depending on the driver type used) . db2java.zip, db2jcc.jar, and db2jcc_license_cu.jar and use them in the App Server ->JVM settings -> Path Settings -> Classpath Suffix
3.) The next setup is dependent on the Type driver you use
I used the Type 4 and this is the resource setup I used.
Connection Pool:
Name: DB2TestPool
Datasource Classname: com.ibm.db2.jcc.DB2SimpleDataSource
Resource Type: javax.sql.ConnectionPoolDataSource
Properties:
user: xxxxxx
password: xxxxxx
databaseName: TEST
serverName: <hostname of machine>
portnumber: 50000
driverType: 4
URL: jdbc:db2://<hostname>:<port>/<database>
JDBC Resource:
JNDI Name: jdbc/TEST
Pool Name: DB2TestPool
With this configuration I was able to ping the database as well as connect to create an entity bean from a table. This should give you a starting point.
I have yet to deploy my application, but should be doing that sometime today to verify that a connection can be made and used from within the application.

Jolt client vs. jolt connection pooling

Similar Messages

Maybe you are looking for