TomCat issue and new help regarding Error - 12296

[gavend]

Hello all,

I need some help to determine why I am getting this error.

Failed to create temp-table database object for TEMP-TABLE {temp table}. (12296)

We run web services and when connecting to the appserver via .net code we get this error message returned from our appserver and tomcat is issuing a 500 error which is causing us some pain. What I think the issue is is that I am not setting my session variables up correctly when first making the connection.

Anyone have some ideas on whether this is the issue or could it be something else. ?

 

[rstanciu]

go to the server side and take a look to appserver logs

 

[sdjensen]

Stop and start your app servers.

What version of Progress do you use?

 

[gavend]

The only thing that is in the logs is this error message

we use 10.2A .. we are stopping and starting the appservers weekly but we stop and start Tomcat to fix the problem. ie it goes away for a while. We are now stopping and starting Tomcat everyday but I don't like this solution.

From my findings we may not be clearing out the objects but I can not seems to find anything left hanging around.

 

[sdjensen]

We have the same problem and I have not been able to find out why the problem occurs.

 

[rstanciu]

what is says the appserver *.server.log ?

 

[Marian EDU]

are you cleaning-up input-output, output temp-tables (even when table-handle is used)?

you can check out if there are any 'orphan' temp-tables you don't expect... http://progress.atgnow.com/esprogre...002&docProp=$solution_id&docPropValue=p113170

 

[gavend]

We actually have some code in our internal appserver to is supposed to delete the redundant objects left around

---------------

[FONT=r_ansi][FONT=r_ansi]PROCEDURE cleanObjects:
/*-----------------------------------------------------------*/
/* Purpose: Clean out the objects left in memory */
/* Parameters: None */
/* Notes: */
/*-----------------------------------------------------------*/
/* ---- Parameters ---- */
/* ---- Variables ---- */
define variable lob-Header as Progress.Lang.Object.
/* ---- Main Block ----*/
assign lob-Header = session:first-object.
if lob-Header = ? then do:
return.
end.
CLEAN-BLOCK:
repeat while lob-Header <> ?:
message "Cleaning up Object - " lob-Header:toString().
delete object lob-Header.
assign lob-Header = session:first-object.
end. /* CLEAN-BLOCK */
END PROCEDURE. /* cleanObjects */

------------------------

but we run an external facing appserver connectted to an internal appserver which is connected to the databases. I could run this same code on there that might bring some information.

Also does anyone know how the assign the session variables on connection to the appserver ?
[/FONT][/FONT]

 

[rstanciu]

in the configuration file of appserver (ubroker.properties) add this variable
srvrActivateProc=srvrActivateProc.p
which is executed every time when appserver executes a *.p
the procedure has any parameters. You can add there you code to assign [FONT=r_ansi][FONT=r_ansi]session variables

[/FONT][/FONT] srvrActivateProc=
Specify activate procedures for AppServers. The procedures must be valid
PROGRESS procedures on the application service PROPATH.

srvrConnectProc=
Specify connect procedures for AppServers. The procedures must be valid
PROGRESS procedures on the application service PROPATH.

srvrDeactivateProc=
Specify deactivate procedures for AppServers. The procedures must be
valid PROGRESS procedures on the application service PROPATH.

srvrDisconnProc=
Specify disconnect procedures for AppServers. The procedures must be
valid PROGRESS procedures on the application service PROPATH.

srvrShutdownProc=
Specifies a shutdown procedure for the server. The procedure must be a
valid PROGRESS procedures on the application service PROPATH.

srvrStartupProc=
Specifies a shutdown procedure for the server. The procedure must be a
valid PROGRESS procedures on the application service PROPATH.

srvrStartupProcParam=
**Currently unused**

[FONT=r_ansi][FONT=r_ansi]

[/FONT][/FONT]

 

[Tarby777]

Mate, did any of this advice solve the problem for you?

I have error 12296 as well. Running 10.2b05 and Tomcat 6 together on a Linux box, trying to call a 4GL routine on a state-free Appserver via the web services adapter. The program runs fine from the procedure editor but when I run it through SoapUI, I get this in the WSA logfile:

Showroom 4GL-Provider
Error in SOAP request execution: ERROR condition:
Unable to create schema information for temp-table ttBranches. (3244) (7211) (10926)

and this in the Appserver's server logfile:

[11/10/19@10:18:48.759+2800] P-004733 T-1125680 1 AS -- Failed to create temp-table database object for TEMP-TABLE ttBranches. (12296)
[11/10/19@10:18:48.759+2800] P-004733 T-1125680 1 AS -- Unable to create schema information for temp-table ttBranches. (3244)

I'm completely stuck, as there seems to be nothing about this in SupportLink or the Communities site, and your question was the only thing that Google returned. Does anyone know what actually causes this error and how to fix it?

TIA
Nick

 

[RealHeavyDude]

Did you design the Temp-Tables using the Temp-Table maintenance tool? If so, did you compile your procedures when the TEMP-DB still was connected?

Heavy Regards, RealHeavyDude.

 

[Tarby777]

Hi RealHeavyDude,

No, they were just created in the procedure editor. Example:

define temp-table ttBranches serialize-name "BranchList"
field branchID as integer serialize-name 'branchID'
field branchName as character format 'x(24)' serialize-name 'branchName'
index idx1 is primary unique branchID.


Regards,
Nick

 

[gavend]

Mine was alittle different as mine code would run and just fall over but what I have had to do for my case was to ensure that all the handles (including the temp-tables) and objects were deleted prior to the program ending. I do not rely on the program garbage collector to clean things up.

[FONT=r_ansi][FONT=r_ansi]i.e ->
if valid-handle({handle-name})
then delete widget {handle-name}.

then delete the objects.

you might try adding a no-undo on the temp-table also...

NO-UNDO
Specifies that when a transaction is undone, changes to the temp-table records need not be undone. If you do not specify this option, all records in the temp-table are restored to their prior condition when a transaction is undone. The NO-UNDO option can significantly increase the performance for temp-table updates; use it whenever possible.


Your error message 3244 seems to indicate that you to [FONT=r_ansi][FONT=r_ansi]NEW SHARED your temp-table somewhere ??[/FONT][/FONT]
[/FONT][/FONT]

 

[Tarby777]

Thanks Gavend. I'll give NO-UNDO a try. I always use it normally... can't think why I didn't do it this time
I'll also try clearing the TT out manually before closing the program down...

The TT isn't shared... the program that gets called by the web service client checks that the database connection is there as expected, then it calls a second program which queries the database and returns a TT to the first program via an "output table" parameter. The first program then serialises the contents of the TT to JSON, which is stored in a LONGCHAR output parameter.

Regards,
Nick

 

[gavend]

also have a look at the by-reference command.
[FONT=r_ansi][FONT=r_ansi]ie input table {temp-table name} by-reference

it might help you...
[/FONT][/FONT]

 

[Tarby777]

I've tried NO-UNDO, BY-REFERENCE and clearing out the TT and I still have the problem (error messages exactly the same as before). I put some traces in both programs and it looks like Progress is giving up as soon as it encounters the first .r, as none of my messages have made it into the Appserver logfile. Even very simple methods that are contained in a single program and perform no database access are exhibiting this behaviour too...

 

[sdjensen]

Are you running low on memory or disk space?

Are you sure that the appserver is running the right .r files? Check propath.

 

[GregTomkins]

If you are having problems where you run something for many times and its fine, then it randomly crashes with seemingly identical inputs, this could be relevant: TC has an issue that if you enable on-the-fly class reloading, it doesn't really work properly and you run out of memory eventually, causing TC to crash. it's not generally a problem for real users (who don't normally reload classes) but it sucks for developers.

Solution: use JRebel (or similar), which (basically) enables this feature properly. JRebel is super-cheap and somehow does this trick (which is a pretty amazing thing, when you think about it) seemingly perfectly.

 

[Tarby777]

Finally, some good news... I'm able to get data back to the client now. It's looking like the problem may have been caused by an Appserver that stayed up when the database it was connected to came down for a backup. Bouncing the Appserver then disabling / enabling the web service for good measure seems to have resolved it.

Cheers,
Nick