Tuesday, December 7, 2010

VisualWorks 7.7.1 Store Using Too Much Memory and Too Many Open Cursors During Load (and Fix)

We have experienced two types of load problems when loading bundles with many changes in Store using VisualWorks 7.7.1:
  • 'ORA-01000: maximum open cursors exceeded'
  • Unhandled exception: a primitive has failed
    The primitive failure is caused by too little memory available. Here is the stack trace:
Glorp.GlorpDatabaseReadError(Glorp.GlorpError)>>signal
Glorp.VWDatabaseAccessor(Glorp.DatabaseAccessor)>>handleError:for:
optimized [] in [] in Glorp.DatabaseAccessor>>executeCommand:returnCursor:
BlockClosure>>cull:
Error(GenericException)>>performHandler:
Error(GenericException)>>propagatePrivateFrom:
Error(GenericException)>>propagateFrom:
Error(GenericException)>>propagate
Error(GenericException)>>raiseSignal
Error class(GenericException class)>>raiseErrorString:
CPointerType(Object)>>error:
CPointerType(Object)>>primitiveFailed
CPointerType(CType)>>primMallocNoRetry:pointerKind:
CPointerType(CType)>>primMalloc:pointerKind:
OracleBuffer>>allocStructuredBuffer:
optimized [] in OracleBuffer>>mallocForRowBuffer
BlockClosure>>ifCurtailed:
OracleBuffer>>mallocForRowBuffer
OracleSession>>allocateRowBufferExternal:
optimized [] in OracleSession>>acquireBuffers


If you get any of these problems, follow the advice Cincom’s Alan Knight gave to the VMNC mailing list:
In StoreLoginFactory>>currentStoreSession, modify it to send "reusePreparedStatements: false". This will remove one of the caching optimizations it uses for these resources. It may make things a bit slower. It also may not fix the problem, I haven't tried it, but I suspect that's the critical resource.
I tested the suggest fix now, and it works. I would recommend that Cincom include the modification in the next version of VisualWorks.

No comments: