ERROR -901/ MAX FILE SIZE EXCEEDED / THREAD DYING ON STARTUP

[Stewart]

We have a thread that is dying on startup.  I am receiving the following error.

[ :10/09/2019 15:48:50] Msg space limit is 0
[ :10/09/2019 15:48:50] Msg parsing reuse is disabled.
[ :10/09/2019 15:48:50] Msg tracing feature is disabled.
[ :10/09/2019 15:48:50] DiskQue Minimum # of Messages/que: 50
[ :10/09/2019 15:48:50] DiskQue Virtual Memory percent:75.000000
[ :10/09/2019 15:48:50] Applying EO config: ”
[ :10/09/2019 15:48:50] Applying EO config: ”
[ :10/09/2019 15:48:58] Thread not auto-started.
[ :10/09/2019 15:48:58] Thread not auto-started.
[ :10/09/2019 15:48:58] No routes defined for TrxId ”
[ :10/09/2019 15:48:58] (-901) ‘RDM Embedded DB error: “INTERNAL error: -901
[ :–/–/—- –:–:–] maximum file size exceeded
[ :–/–/—- –:–:–] C errno = 0: Success”
[ :–/–/—- –:–:–] ‘

 

Any ideas?

 

Topic

[Charlie Bursell]

I would suggest you contact Support.

[Stewart]

Charlie Bursell,

Have you seen this before?

[Charlie Bursell]

I have seen similar errors.  Support will be able to log in and gather more data.

[Edward Figueroa]

The DB error -901 means that the RDM Embedded runtime memory has been corrupted.

Resolution is to bring the site down and run thru a cleanup.

[Stewart]

I’m fairly new to Cloverleaf.  How does the memory become corrupted?  What’s the process for a cleanup?

 

[Matthew Bozek]

I’m running into the same issue and looking for guidance as well (actually the exact same error verbatim). Is there documentation on how to run the cleanup?

[Anthony Kirk]

To start you need to ensure there are no other users accessing your site.  Stop any remaining processes that are running – attempt to do so in an order that flushes any messages through first.  Wait for that to complete.  If there are any messages in the error and recovery databases you haven’t handled yet and can still access, bearing in mind your error message suggests the error database itself is corrupt, dump what you can to a file/files.

Then through a shell window (open from the runtime menu if you need) paste the commands in the attached CleanUp.txt file – extracted from an old iSoft clean-up script.  This begins by stopping the Monitor Daemon, deletes the shared memory from the exec folder, removes the region from the statistics interface (the “-Z” switch zeros the statistics too but that’s personal preference), then rebuilds the error and recovery databases.  It’ll warn you “this is an extremely destructive operation – do you wish to continue?”  It’s Hobson’s choice really!  You’ll get an error if the files are in use (remember I mentioned you need to kick off anyone else earlier) and the operation will fail. Otherwise you’ll be good to go and can start the monitor daemon and bring the interfaces back up.  Don’t forget to send those messages you salvaged from the recovery database first, if you had any.

We normally run through this whenever there’s a “panic”, so error messages may still be salvageable in that state.

Attachments:

You must be logged in to view attached files.

[Author]

Replies