This content has been marked as final. Show 4 replies
I'm not sure exactly what you are asking. SVCTIMEOUT is the maximum time Tuxedo will allow a service to execute before concluding that the server executing the service is hung or looping. Normally this should be set to a value far in excess of the normal execution time for the service to allow for slower response some of the time. So say if the service normally takes 10 seconds to execute, and the worst its ever seen to execute and still return results is 30 seconds, then set the SVCTIMEOUT to something greater than 30, say 35 or 40 seconds, or even a minute or two. The goal is to prevent a hung or looping server from consuming resources for something that may never complete.
The portion of your UBBCONFIG file that you've posted doesn't give the SVCTIMEOUT. What is the expected response time of the service? What is SVCTIMEOUT set to?
With regards to being able to execute the request from SQLPlus, there could be many reasons that works while your Tuxedo service doesn't. For example, the Tuxedo service may have involved distributed loosely coupled transactions that ended up in a deadlock. Without knowing more details, it's hard to speculate what exactly is happening.
Oracle Tuxedo Chief Architect
Thanks for the attention given to this case
For TUXEDO 11 64 bits, I am working with Oracle precompiler Pro * C version 11g accessing an Oracle 9i database
The call to service via the WSL am doing through a TUXEDO client program made in Microsoft Visual C++
WSL SRVGRP="WSLGRP1" SRVID=501
CLOPT="-A -t -- -n //10.162.14.97:20000 -m 1 -M 10 -x 10 -p 20000 -P 20010"
RQPERM=0666 REPLYQ=N RPPERM=0666 MIN=1 MAX=10 CONV=N
MAXGEN=60 GRACE=3600 RESTART=Y
The SVCTIMEOUT is located at 120 but just call the Oracle 9i package compiled in Pro * C and then TUXEDO service crashes
Annex code to call a Oracle 9i Package from TUXEDO service ST_A_PreActPSP
userlog(" Obtuvo datos del FML ***************> ");
userlog(" sCMercado [%s], sCHomeArea [%s], sCMarca [%s], sCModelo [%s], shTipoServicio [%d], sCTipoCentral [%s], sCTecnologia [%s], sCSerial [%s] , sCUsuario [%s] ", sCMercado, sCHomeArea, sCMarca, sCModelo, shTipoServicio, sCTipoCentral, sCTecnologia, sCSerial, sCUsuario);
EXEC SQL WHENEVER SQLERROR GOTO ERR;
EXEC SQL EXECUTE
Also Annex of the UBBCONFIG where I place
DEFAULT: AUTOTRAN=Y TRANTIME=90 SVCTIMEOUT=120
Intel Pentium 4 HT 64 Bits
Oracle Solaris 11 64 bits
Tuxedo 11 Intel 64 bits
Oracle 11g for Solaris 64 bits Intel without database
Oracle 9i database in another server
Memory RAM 2 GB
In advance thank you for attending the event and appreciate all the help I can provide
Caracas - Venezuela
FYC Soluciones Integrales C.A.
Edited by: lmayora on 03-may-2012 7:18
Edited by: lmayora on 03-may-2012 7:52
I don't think you're experiencing a service timeout at all. If Tuxedo kills a server due to SVCTIMEOUT, there should be a log message to that effect in the ULOG. I suspect what is happening is that your SQL statement is causing the process to exit, likely do to a segment fault or other similar problem. I would suggest running the server in the debugger and see what happens when you step into the SQL statement. Alternatively, you could enable process dumps and then examine the dump file that should be generated.
The error message you are seeing:
160801.tuxfyc01!BBL.22554.1.0: LIBTUX_CAT:541: WARN: Server g_pspcc01/408 terminated
Indicates that the server process exited without executing Tuxedo exit routines, i .e., terminated without cleaning up.
Oracle Tuxedo Chief Architect
Creo que Todd tiene razon, tiene pinta que el codigo da un core y eso provoca la caida del servidor, intenta ver si teneis activado los cores en la maquina servidora, ya que deberia dejar archivo de core para poder analizarlo o debuggear el server. Otra cosa que se me ocurre es que aumentes las trazas xa el server por si pudiera dar algo mas de informacion por probar.
Sorry for using Spanish.