OpenROAD Server connectivity issue
Martin Bloomfield
Hello All,
We are having an issue with losing the connection between OpenROAD server and our Ingres database.
We have two web servers that share an OpenROAD service located on one of these web servers. The OpenROAD applications on one web server are mainly stateless, and the other are all stateful. The OpenROAD service is on the server with the stateful apps.
We switch the OpenROAD service off every night for an hour. After it comes back all the apps work. However, the stateless apps on frequent occasions stop working due to being disconnected from the database, but the associated ASO process is still running (we log the process id on startup). The stateful apps generally continue working.
Restarting the OpenROAD service fixes the issue; as does manually killing the ASO process in task manager for the effected apps.
There are no obvious errors in the Ingres Log on the database server, but the ASO logs report database connections lost.
Has anyone come across this situation? Or have any suggestions about its resolution?
We are intending to implement a “keep alive” call to the database running every 15 minutes on a user event (in the aso_ghost_start component) to see if we have a loss of database connectivity. If we identify the loss of database connectivity, is there a way of restarting the effected ASO process from within the ASO image?
We are running OpenROAD 6.2 p15043 and Ingres db 11.1 p15547.
Many Thanks,
Martin Bloomfield
Application Developer & Database Administrator
Information Systems Development
Information, Technology and Facilities
Health and Safety Executive
YORK
Follow HSE on Twitter @H_S_E
*****************************************************************************************************************
Please note : Incoming and outgoing email messages are routinely monitored for compliance with our policy on the use of electronic communications and may be automatically logged, monitored and / or recorded for lawful purposes by the GSI service provider.
Interested in Occupational Health and Safety information?
Please visit the HSE website at the following address to keep yourself up to date
*****************************************************************************************************************
Bodo Bergmann
Hi Martin,
The “keepalive” mechanism using a user event will NOT work, as there is no event processing in a server application.
This is clearly documented in the Server Reference Guide (https://docs.actian.com/openroad/11.2/index.html#page/ServerRef/Ghost_Frame.htm):
Note: Event
blocks in the ghost frame will never be executed.
An application running under the OpenROAD Server context is driven entirely by synchronous 4GL procedure calls and not by any other kinds of events.
In case of a lost database connection, why do you just do a reconnect to the database rather than restarting the server application?
E.g. in your server 4GL procedures (SCPs) you could just execute an SQL statement (e.g. a COMMIT) at the beginning.
Then check it’s error status (iierrornumber) – if it’s indicating a connection error, then do a
reconnect.
Also make sure that you clear the error flag for your application (SessionObject) before returning from the procedure.
procedure x() =
declare
db = VARCHAR(256) NOT NULL;
flags = VARCHAR(256) NOT NULL;
enddeclare
{
COMMIT;
IF iierrornumber <> 0 THEN
// Try reconnecting
db = CurExec.DBSession.Database;
flags = CurExec.DBSession.Flags;
CurExec.DBSession.Disconnect();
IF CurExec.DBSession.Connect(database = db, flags = flags) = ER_OK THEN
CurExec.Trace(text = ' Application $_ApplicationName reconnected to database: ' + db);
ELSE
CurExec.Trace(text = 'Application $_ApplicationName FAILED reconnection to database: ' + db + HC_NEWLINE +
'Forcing application restart.');
cnt = 1/0; // Force runtime error (division by zero) to restart server on next call
RETURN -1; // No ClearErrorFlag() here as we want to force the restart
ENDIF;
ENDIF;
// Do your normal processing
…
CurSession.ClearErrorFlag();
RETURN cnt;
}
HTH.
Regards,
Bodo.
Bodo
Bergmann
Engineering Architect
Actian | OpenROAD Engineering
www.actian.com
GESELLSCHAFTSANGABEN: Actian Germany GmbH | Sitz der Gesellschaft: Halenreie 42, 22359 Hamburg
| Geschäftsführung: Stephen Padgett, Marc Monahan | Handelsregister: Amtsgericht Hamburg | HRB 135991 | USt-IdNr: DE252449897
--
You received this message because you are subscribed to the Google Groups "OpenROAD Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openroad-user...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/openroad-users/CWLP123MB48689B20D566B56669EDA45EC6349%40CWLP123MB4868.GBRP123.PROD.OUTLOOK.COM.
Bodo Bergmann
Slight corrections (declaration of “cnt” variable and RETURN statements) in the 4GL example code:
procedure x() =
declare
db = VARCHAR(256) NOT NULL;
flags = VARCHAR(256) NOT NULL;
cnt = INTEGER NOT NULL;
enddeclare
{
COMMIT;
IF iierrornumber <> 0 THEN
// Try reconnecting
db = CurExec.DBSession.Database;
flags = CurExec.DBSession.Flags;
CurExec.DBSession.Disconnect();
IF CurExec.DBSession.Connect(database = db, flags = flags) = ER_OK THEN
CurExec.Trace(text = ' Application $_ApplicationName reconnected to database: ' + db);
ELSE
CurExec.Trace(text = 'Application $_ApplicationName FAILED reconnection to database: ' + db + HC_NEWLINE +
'Forcing application restart.');
cnt = 1/0; // Force runtime error (division by zero) to restart server on next call
RETURN; // No ClearErrorFlag() here as we want to force the restart
ENDIF;
ENDIF;
// Do your normal processing
…
CurSession.ClearErrorFlag();
RETURN;
}
Bodo.
From:
Bodo Bergmann
Sent: Tuesday, February 15, 2022 3:05 PM
To: openroa...@googlegroups.com
Subject: RE: OpenROAD Server connectivity issue
Hi Martin,
The “keepalive” mechanism using a user event will NOT work, as there is no event processing in a server application.
This is clearly documented in the Server Reference Guide (https://docs.actian.com/openroad/11.2/index.html#page/ServerRef/Ghost_Frame.htm):
Note: Event blocks in the ghost frame will never be executed.
An application running under the OpenROAD Server context is driven entirely by synchronous 4GL procedure calls and not by any other kinds of events.
In case of a lost database connection, why do you just do a reconnect to the database rather than restarting the server application?
E.g. in your server 4GL procedures (SCPs) you could just execute an SQL statement (e.g. a COMMIT) at the beginning.
Then check it’s error status (iierrornumber) – if it’s indicating a connection error, then do a reconnect.
Also make sure that you clear the error flag for your application (SessionObject) before returning from the procedure.
procedure x() =
declare
db = VARCHAR(256) NOT NULL;
flags = VARCHAR(256) NOT NULL;
cnt = INTEGER NOT NULL;
enddeclare
{
COMMIT;
IF iierrornumber <> 0 THEN
// Try reconnecting
db = CurExec.DBSession.Database;
flags = CurExec.DBSession.Flags;
CurExec.DBSession.Disconnect();
IF CurExec.DBSession.Connect(database = db, flags = flags) = ER_OK THEN
CurExec.Trace(text = ' Application $_ApplicationName reconnected to database: ' + db);
ELSE
CurExec.Trace(text = 'Application $_ApplicationName FAILED reconnection to database: ' + db + HC_NEWLINE +
'Forcing application restart.');
cnt = 1/0; // Force runtime error (division by zero) to restart server on next call
RETURN; // No ClearErrorFlag() here as we want to force the restart
ENDIF;
ENDIF;
// Do your normal processing
…
CurSession.ClearErrorFlag();
RETURN;
Martin Bloomfield
Hi Bodo,
Thank you for this. As I have a lot of places where I’m likely to need this, I’ll try putting this into a separate procedure “CheckConnection_pr” and call it from all of the entry points into the App Server.
Regards,
Martin Bloomfield
Application Developer & Database Administrator
Information Systems Development
Information, Technology and Facilities
Health and Safety Executive
YORK
Follow HSE on Twitter @H_S_E
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
--
You received this message because you are subscribed to the Google Groups "OpenROAD Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openroad-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openroad-users/SJ0PR06MB78051DCEDF1984AE866ED23493349%40SJ0PR06MB7805.namprd06.prod.outlook.com.