Managed to crash appserver, by a READ-JSON

How big is the json payload?

What happens if you create a stub program to read it in from a file instead of the appserver route?

This is full program....

(changed the object oriented  to procedural code, thinking the object was the culprit..)

//USING dw.dwpromodesempeno FROM PROPATH.

DEFINE INPUT PARAMETER TABLE FOR ttPoolAS.

DEFINE VARIABLE lRetOK     AS LOGICAL  NO-UNDO.
//DEFINE VARIABLE cDesempeno AS CLASS    DW.dwPromoDesempeno NO-UNDO.

/* ***************************  Main Block  *************************** */

FIND FIRST ttPoolas.
MESSAGE STRING(ttpoolas.json1).

lRetOK   = DATASET dsdwPromoDesempeno:READ-JSON("LONGCHAR", ttPoolAS.JSON1 , "EMPTY").

FIND dwPromoDesempeno NO-LOCK
   WHERE dwPromoDesempeno.Fecha    = ttdwPromoDesempeno.Fecha
   AND   dwPromoDesempeno.Nomina   = ttdwPromoDesempeno.Nomina
   AND   dwPromoDesempeno.Articulo = ttdwPromoDesempeno.Articulo  no-error.

//IF AVAILABLE(dwPromoDesempeno) THEN
//    cDesempeno:UpdatedwPromoDesempeno(INPUT-OUTPUT DATASET dsdwPromoDesempeno).
//ELSE
//    cDesempeno:createdwPromoDesempeno(INPUT-OUTPUT DATASET dsdwPromoDesempeno).

last code was ported to procedural syntax, to no avail, as the error is fired from the  lRetOK = DATASET.... line

and this is the output from the MESSAGE STRING(ttPoolAS.JSON1). line:

[16/09/02@21:13:08.627-0500] P-012872 T-015016 1 AS -- (Procedure: 'procs\ventas\pPromo.p' Line:128) {"dsdwPromoDesempeno": {
[16/09/02@21:13:08.627-0500] P-012872 T-015016 1 AS -- (Procedure: 'procs\ventas\pPromo.p' Line:128)   "ttdwPromoDesempeno": [
[16/09/02@21:13:08.627-0500] P-012872 T-015016 1 AS -- (Procedure: 'procs\ventas\pPromo.p' Line:128)     {
[16/09/02@21:13:08.627-0500] P-012872 T-015016 1 AS -- (Procedure: 'procs\ventas\pPromo.p' Line:128)       "Sucursal": 42,
[16/09/02@21:13:08.627-0500] P-012872 T-015016 1 AS -- (Procedure: 'procs\ventas\pPromo.p' Line:128)       "Nomina": 1,
[16/09/02@21:13:08.627-0500] P-012872 T-015016 1 AS -- (Procedure: 'procs\ventas\pPromo.p' Line:128)       "Fecha": "2016-09-02",
[16/09/02@21:13:08.627-0500] P-012872 T-015016 1 AS -- (Procedure: 'procs\ventas\pPromo.p' Line:128)       "Articulo": "ADOBADO",
[16/09/02@21:13:08.627-0500] P-012872 T-015016 1 AS -- (Procedure: 'procs\ventas\pPromo.p' Line:128)       "Kilos": 1.0,
[16/09/02@21:13:08.627-0500] P-012872 T-015016 1 AS -- (Procedure: 'procs\ventas\pPromo.p' Line:128)       "Tickets": 1
[16/09/02@21:13:08.627-0500] P-012872 T-015016 1 AS -- (Procedure: 'procs\ventas\pPromo.p' Line:128)     }
[16/09/02@21:13:08.627-0500] P-012872 T-015016 1 AS -- (Procedure: 'procs\ventas\pPromo.p' Line:128)   ]
[16/09/02@21:13:08.627-0500] P-012872 T-015016 1 AS -- (Procedure: 'procs\ventas\pPromo.p' Line:128) }}

TIA

My FAULT!!!!

Sorry for the distraction...

Problem was that ttAS.Json field is clob.

I copy the field value to longchar var, and called READ.JSON for taht value, and worked!!!

I'm sorry...

And thanks to everyone involved.

I think you should log that as a bug. It should either throw a compile error or work, but certainly not crash the AVM at runtime.

I would do.. but PSC cut me off...

Now all stuff related to psc, should be routed throug vendor, wich in turn won't pay too much attention to a bug report, as it is not a sale... in a nice event that vendor is willing to throw case to next level of support, it will be routed to Xweb, the company representing PSC here in Mexico... and next week perhaps I'll have some answer about it being recorded as bug...

I have not priority support... just mon-fri 9:00 - 17:00.  it means if my database stops friday night, all work on saturday and sunday should be halted, I guess. Can you imagine?   I hope my year renew also lowers it's price!

(i'll post the bug, and report back)

Octavio, a next time, you should look at the AppServer.server.log say rather than the broker.  The server log is the log of the _proapsv.exe agent that really processes the ABL code (the broker just passes a client request to an agent) and it catchs ABL error messages.

If the server.log reports a simple ABL error message then it's fine (just an application bug) and then it should not be called a "crash".  A crash case is when the ABL process dies (then it's an ABL bug to be reported to Tech Support)

I think the abl process dies. That can be seen from the broker log. If I run the following from prowin32 in 11.3.2 and 11.6 it also kills the process (after giving a runtime error message that does state what the problem is.) Since Octavio gave the output of the messages that would have shown up in the server log file I'd assume he checked the server log too.

DEFINE VARIABLE c AS CHARACTER  NO-UNDO.

assign c = '~{"dsdwPromoDesempeno":

~{ "ttdwPromoDesempeno": [~{

     "Sucursal": 42,

     "Nomina": 1,

     "Fecha": "2016-09-02",

     "Articulo": "ADOBADO",

     "Kilos": 1.0,

     "Tickets": 1

   ~}

 ]

~}~}'.

define variable hds as handle no-undo.

create dataset hds.

hds:read-json("longchar", c, "empty").

Today I got the answer from support...   It will be logged as a bug....

Keep it up!

(was assigned : PSC00350571)

and KB  knowledgebase.progress.com/.../AppServer-crashes-using-a-CLOB-with-READ-JSON-method