[GS/SS Beta] GbsRtErrLostSessionState
Locked
 
|
While doing a data load from a number of files, I keep getting this error at different points. The import can be restarted at the last commit point, after logging out and back in to GS... Unhandled exception: GS Server Error - GbsRtErrLostSessionState - a ImproperOperation occurred (error 2364), The object aGsFile that has some associated session state has lost that transient state. Examples
of classes that use session state are GsSocket and GsFile. [1] GS: GsFile >> userAction:onClient:with:with: (envId 0) @1 line 1 [2] GS: GsFile >> _seekTo:opcode: (envId 0) @10 line 13 [3] GS: GsFile >> position: (envId 0) @2 line 6 ... ...has anyone else seen this problem? (I have also sent in a help request to GS) I've seen this problem posted for GsSocket, but not for GsFile. We are running GS 3.1.0.5 on Linux 2.6.18 While trying various ways to work around the problem I also got 'errno=24,EMFILE, The
process has too many open files' so I had the limits raised, and for 'ulimit -n' I now get 32768, but the GbsRtErrLostSessionState persists. Any suggestions? Thanks, Bob Nemec
Bob Nemec
|
Re: [GS/SS Beta] GbsRtErrLostSessionState
|
|
Bob, Both GsSocket and GsFile use ephemeral state that's held in the C layer. This information is lost if the session logs out and logs back in, or is referenced by a different session that wasn't involved with opening the socket/file. For this reason you shouldn't persist GsFile or GsSocket objects. ------------------------------------------------------------------------ Bill Erickson GemTalk Systems Engineering 15220 NW Greenbrier Parkway #240, Beaverton OR 97006 ------------------------------------------------------------------------ On Thu, Dec 12, 2013 at 1:26 PM, <[hidden email]> wrote:
|
|
|
Thanks Bill, The instances in this case are held by a _sessionStateAt: entry. I don't try to hold on to the GsFile instance between logins. I'm working on changing the import code to read the file once, rather than position the read stream pointer back and forth. Imports that read one large file work fine, the ones that re-read many smaller files are the ones that fail. There may have been issues with another session reading the same data. I'll rerun the import while verifying that no other sessions are logged in. Bob On Thursday, December 12, 2013 5:40:17 PM, Bill Erickson <[hidden email]> wrote: Bob, Both GsSocket and GsFile use ephemeral state that's held in the C layer. This information is
lost if the session logs out and logs back in, or is referenced by a different session that wasn't involved with opening the socket/file. For this reason you shouldn't persist GsFile or GsSocket objects. ------------------------------------------------------------------------ Bill Erickson GemTalk Systems Engineering 15220 NW Greenbrier Parkway #240, Beaverton OR 97006 ------------------------------------------------------------------------ On Thu, Dec 12, 2013 at 1:26 PM, <[hidden email]> wrote:
Bob Nemec
|
Re: [GS/SS Beta] GbsRtErrLostSessionState
|
|
In reply to this post by Bob Nemec
Bob,
Another explanation might be involve your gsFile instance becoming persistent? I think you are permitted to make instances of GsFile and GsSocket persistent but the transient session state associated with c layer (mentioned by Bill) will be lost if the GsFile/GsSocket instance is persisted and then flushed from the vm ... I'll double check with the vm guys on Monday. Dale From: [hidden email] |
|
|
Dale, I fixed my problem by reading the entire contents of the file and replacing the old file read stream with a read stream on the contents string. The GsFile read is now quick (tens of milliseconds) and I no longer have to keep an open file handle. Works like a charm. Bob On Saturday, December 14, 2013 7:48:04 PM, Dale K. Henrichs <[hidden email]> wrote: Bob, Another explanation might be involve your gsFile instance becoming persistent? I think you are permitted to make instances of GsFile and GsSocket persistent but the transient session state associated with c layer (mentioned by Bill) will be lost if the GsFile/GsSocket instance is persisted and then flushed from the vm ... I'll double check with the vm guys on Monday. Dale From: [hidden email]
Bob Nemec
|
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |